VoIP. Thomas Leutermann Universität Osnabrück

Transkript

1 VoIP Thomas Leutermann Universität Osnabrück Die Ausarbeitung zum Thema Voice over IP stellt die Grundlagen und wesentlichen verwendeten Protokolle dar. Zusätzlich wird kurz auf die Entstehung und die aktuellen Einsatzgebiete eingegangen. Inhaltsverzeichnis 1 Einführung... 2 Entstehung und Organisationen Protokolle und Standards im Überblick Digitalisierung und Codierung Transport der digitalen Sprachdaten Real-Time Transport Protocol Real-Time Transport Control Protocol Protokolle zur Signalisierung Session Initiation Protocol SIP Proxy-Mode und Redirect-Mode SIP-Nachrichten Ablaufsteuerung zwischen verschiedenen Netzen Telefonnummern-Systematik und Internet-Adressierung Schlussbetrachtung Literaturverzeichnis und Web-Links VoIP Diensteanbieter Anlagen... 23

2 1 Einführung 2 1 Einführung Voice over Internet Protocol, Voice over IP oder kurz VoIP ermöglicht eine Sprachkommunikation über das Internet bzw. über Netze, die das Internet Protocol nutzen. Sprachkommunikation bedeutet, dass Nutzer miteinander interagieren, so dass eine Übertragung in Echtzeit erfolgen muss. Außerdem soll, wie in der klassischen Welt der Telefonie, jeder Nutzer mit einem Netzzugang prinzipiell mit jedem andern Nutzer eine Verbindung aufnehmen können. Dem entsprechend sind die Anforderungen, die an die Vermittlung einer Verbindung und an die Übertragung eines Gespräches gestellt werden, im digitalen, Datenpakete versendende Internet zu realisieren. Der folgende Beitrag gibt einen Überblick über die Entstehung, die notwendigen Protokolle und Standards und die technischen Realisierungen von VoIP. Außerdem soll kurz auf die Nutzung und auf aktuelle Entwicklungen eingegangen werden.

3 2 Entstehung und Organisationen 3 2 Entstehung und Organisationen Die Anfänge des Telefonierens über Datennetze liegen in der Übertragung von Sprache im Arpanet (Advanced Research Projects Agency Network), dem Vorfahrendes Internets, mittels Network Voice Protocol (NVP) [1] 1, das 1973 entwickelt und 1977 in dem Request for Comments 741 (RFC 741) [2] 2 festgelegt wurde. Das NVP stellt damit den Vorläufer der VoIP-Protokollfamilie dar, hat aber heute keine Bedeutung, obwohl es im Internet Protocol mit der Protokollnummer 11 (NVP-II) geführt wird. Die Entwicklung des Arpanet zum Internet und dessen nach und nach entstandenen Protokolle bilden heute die Grundlage für verschiedenste Dienste. Zunächst war nur die reine Datenkommunikation und die Robustheit der Datenübertragung gegenüber Störungen und dem Ausfall von Teilen des Übertragungsnetzes wichtig (aktualisiert 1981) wurden die wichtigsten dieser Protokolle veröffentlicht: User Datagram Protocol (UDP), RFC 768 (1980) [3] 3 Internet Protocol (IP), RFC 791 IPv4 (1981) [4] 4 Transmission Control Protocol (TCP), RFC 793 (1981) [5] Telnet FTP TFTP TCP UDP Internet Protocol & ICMP Local Network Protocol Protocol Relationships Abbildung 1: Übersicht aus IPv4, RFC 791 Im gleichen Jahr wurde auch die ITU-T-Empfehlung (damals noch CCITT) für ISDN verabschiedet, die ebenfalls prägend für die weitere Entwicklung sein sollte. Die nächsten Schritte wurden getan mit dem Real-Time Transport Protocol (RTP) (1996 als Protokoll zur Echtzeitkommunikation im RFC 1889; seit 2003 RFC 3550), dem ITU-T-Rahmenwerk H.323 u.a. zur Signalisierung (1998), dem Session Initiation Protocol (SIP) (1999 im RFC 2543) als eine Alternative zur Signalisierung im H.323 ITU-Standard sowie mit der SIP-Erweiterung im RFC 3261 in 2002 und dem Standard ITU Q für die Interoperabilität zwischen SIP und ISDN User Part. Damit waren die wichtigsten Grundlagen gelegt, um auch die Übertragung von Sprache/Audio und Video in einem datenpaketvermittelnden Netz zu ermöglichen. Nach einem kleinen Zwischenhoch des Interesses an der Thematik auf Basis von H.323 um das Jahr 2000 herum, kam es zu einem großen Interesse ab 2004, wo sich VoIP im Consumer-Bereich als Massenbewegung etablierte. Treibend war der Erfolg des Unternehmens Skype, dem viele weitere Anbieter, u.a. auch klassische

4 2 Entstehung und Organisationen 4 Telekommunikationsunternehmen folgten. Als Signalisierungs-Protokoll kommt hier seit dem vor allem SIP zum Einsatz. [6] 6 Die Entwicklung im Business-Bereich war geprägt durch das Bestreben Kosten zu senken und die Effizienz zu steigern. Nachdem in den meisten Unternehmen die lokale Rechnervernetzung (LAN) und die Nutzung des Internets gängig war, wurden einerseits die lokalen TK-Anlagen mit dem LAN verbunden und andererseits eine Standortvernetzung über das Internet betrieben. Neben den deutlich verringerten Verbindungsentgelten kam die Effizienzsteigerung insbesondere durch die Computer Telephony Integration (CTI), also die Integration von Sprachkommunikation, , Web, Fax, usw. und das Call Routing innerhalb von bzw. zwischen Firmenstandorten. Die Möglichkeit die Sprach- und auch Videokommunikation gänzlich auf die IP-Basis zu verlagern und die alten TK-Netze zu ersetzen wird seither zunehmend genutzt und ermöglicht auch kleinen Unternehmen den standortübergreifenden, globalen Einsatz. Häufig verschwimmen hier die Grenzen der Consumer- und Business-Angebote, die VoIP als Grundlage haben. Die aktuelle Entwicklung geht hin zu konvergenten Netzwerken, in denen VoIP aufgeht. Die Schlagworte sind Multimedia-Kommunikation, Triple- und Quad-Play (Fernsehen, Telefonieren und Internet sowie Mobilfunk), All-IP-Network bzw. Next Generation Network (NGN) und IP Multimedia Subsystem (IMS) sowie der Wandel der klassischen Telekommunikationsunternehmen hin zu Content Service Providern. Als Organisationen, die die Entwicklung begleiteten und auch heute im wesentlichen noch steuern sind besonders zu nennen Internet Engineering Task Force (IETF) 7, die u.a. die Internet Drafts (ID) - Vorschläge für einen neuen oder erweiterten Internet-Standard - diskutiert und ggf. als Request for Comments (RFC) - Internet-Standard - heraus gibt. Die Arbeiten werden in so genannten Working Groups durchgeführt. 8 International Telecommunication Union, mit der Abteilung Telecommunication Standardization Sector (ITU-T) 9, die mit ihren Study Groups weltweite Standards zur Technik und Tarifierung in der Telekommunikation festlegt. European Telecommunication Standards Institute (ETSI) 10, zuständig für die Standards und Normen in der Informationstechnik und Telekommunikation auf europäischer Ebene. Die Arbeit ist in Technical Bodies (Technical Committee, ETSI Project und ETSI Partnership Project) organisiert weiteres zur Organisation IETF in 'The TAO of IETF',

5 5 3 Protokolle und Standards im Überblick Neben den bereits genannten wichtigsten Protokollen und Standards gibt es weitere Standards für die Übertragung und Vermittlung, die sich mit den Themen Digitalisierung und Codierung der analogen Sprachsignale, Transport der digitalen Sprachdaten, Signalisierung für den Auf- und Abbau und die Steuerung einer Verbindung, Ablaufsteuerung zwischen verschiedenen Netzen und Verbindung der Telefonnummern-Systematik mit der Internet-Adressierung beschäftigen. Außerdem sind Anforderungen an die Qualität der Übertragung vom Sender an den Empfänger zu berücksichtigen, um eine ausreichende Sprachverständlichkeit zu erreichen, die sich an der Qualität herkömmlicher analoger und digitaler Telefonverbindungen messen lassen muss. VoIP ist eine isochrone Verbindung, d.h. es müssen gleiche Zeitabstände zwischen den Datenpaketen auf Sende- und Empfangsseite gegeben sein. Die wichtigsten Parameter der Quality of Service (QoS), die die Isochronität beeinflussen sind 11 : Bandbreite des Übertragungsweges - hier muss eine definierte Mindestbandbreite gegeben sein Ende-zu-Ende-Verzögerung (Delay) - Zeit, die ein Signal vom Sender zum Empfänger benötigt; eine Laufzeit der Signale zwischen 150 ms bis 300 ms oder niedriger wird als ausreichen angesehen, über 300 ms ist nicht mehr akzeptabel Schwankungen der Übermittlungszeit (Jitter) - kann durch einen Jitter-Buffer ausgeglichen werden Paketverluste (Packet Lost Rate) - vereinzelte Paketverluste stellen noch kein Problem dar, Häufungen führen zu störenden Unterbrechungen Zur Orientierung für die weiteren Beschreibungen hier die Darstellung der verwendeten Protokolle und Standards für VoIP in einem Bild, die die Beziehungen und Abhängigkeiten veranschaulichen vgl. Badach 2007, S. 99 ff. 12 Anmerkung: Die Abkürzungen in dem Bild sowie die konkreten Abhängigkeiten werden in den nachfolgenden Kapiteln erläutert.

6 6 Abbildung 3.1: Übersicht VoIP-Protokolle In den nachfolgenden Kapiteln wird eine Übersichten der Standards gegeben. Ist eine Zuordnung in das vier Schichten umfassende TCP/IP möglich, so wird diese mit angegeben. In der nachfolgend Tabelle werden die Schichten kurz beschrieben.[1] 13 TCP/IP model - DoD model 4. Application layer/ Process layer Die Anwendungsschicht umfasst alle Protokolle, die mit Anwendungsprogrammen zusammenarbeiten und die 3. Transport layer/ host-to-host layer Netzwerkinfrastruktur für den Austausch anwendungsspezifischer Daten nutzen. Die Transportschicht stellt eine Ende-zu-Ende-Verbindung (host to host) her. 2. Network layer/ Internet layer Die Vermittlungsschicht ist für die Weitervermittlung von Paketen und die Wegewahl (Routing) zuständig. Auf dieser 1. Network access layer Schicht und den darunter liegenden Schichten werden Punkt-zu-Punkt-Verbindungen betrachtet. Die Aufgabe dieser Schicht ist es, zu einem empfangenen Paket das nächste Zwischenziel zu ermitteln und das Paket dorthin weiterzuleiten. Die Netzwerkschicht ist im TCP/IP-Referenzmodell spezifiziert, enthält jedoch keine Protokolle der TCP/IP-Familie. Sie ist vielmehr als Platzhalter für verschiedene Techniken zur Datenübertragung von Punkt zu Punkt zu verstehen. Die Internet-Protokolle wurden mit dem Ziel entwickelt, verschiedene Subnetze zusammenzuschließen. Daher kann die Host-an-Netz-Schicht durch Protokolle wie Ethernet, FDDI, PPP (Punkt-zu-Punkt-Verbindung) oder (WLAN) ausgefüllt werden. Tabelle 3.1: TCP/IP Schichten-Modell 3.1 Digitalisierung und Codierung Die Umsetzung und Aufbereitung der Sprachsignale in eine digital übertragbare Form kann mit einer Vielzahl an Verfahren durchgeführt werden. Entscheidend für die Auswahl ist der Frequenzumfang des Ursprungssignals, die gewünschte Qualität auf der Empfängerseite und die Bandbreite des Übertragungsweges. Man unterscheidet bei der Sprachcodierung nach (a) Abtastwert-orientierten (sample-based) und (b) Segment-orientierten (frame-based) Verfahren. Im ersten Fall erfolgt eine Abtastung des analogen Sprachsignals mit einer Abtastrate von meist 8 khz und einer anschließenden linearen oder nichtlinearen Quantisierung und Codierung. Auf der Empfängerseite werden die Abtastsignale decodiert, regeneriert und mittels Tiefpassschaltung geglättet. Übersicht der wichtigsten internationalen CODEC Spezifikationen [1] 14 [2] 15 Codec G.711 Name Transfer RateFrequency Quality / MOS Pulse Code Modulation (PCM)\56 o. 64 kbit/s 300 bis ISDN / 4.3 A-law and µ-law (a) 3400 Hz

7 7 G.726 Adaptive Differential Pulse Code16-40 kbit/s Modulation (ADPCM) (a) - / 3.8 G.728 Low Delay Code Excited Linear16 kbit/s Prediction (LD-CELP) (b) 300 bis 3400 Hz nearly ISDN / 3.6 G.729/ G.729A Conjugate Structure Algebraic 8 kbit/s Code Excited Linear Prediction (CS-ACELP) (b) 300 bis 3400 Hz / 3.9, 3.7 G Multiple Maximum Likelihood Quantization (MPMLQ) (b) 6,3 kbit/s 300 bis 3400 Hz / 3.9 G.723 Algebraic Code Excited Linear 5,3 kbit/s Prediction (ACELP) (b) - / 3.6 Speex Free patent audio compression4-15 kbit/s 8 khz medial Narrow-band(free), \ Code Excited Linear GSM Prediction (CELP) (b) Speex\\\ Wide-band Free patent audio compression10-28 kbit/s (free), \ Code Excited Linear Prediction (CELP) (b) khzbetter GSM DVI4 Adaptive Differential Pulse Code32 kbit/s Modulation (ADPCM) (a) 8 khz - ilbc Internet Low Bit Rate Codec (free) (b) 13,3 kbit/s 8 khz / 4.1 G MLT 24 kbit/s 16 khz - l16 PCM Linear PCM at 16 bits per sample (a) 128 kbit/s - - EVCR Enhanced Variable Rate Codec,8 kbit/s Relaxed Code Excited Linear Prediction (RCELP) (b) - - H.263 Videocodec Discrete Cosine Transformation (DCT) kbit/s - medium H.261 Videocodec DCT kbit/s - low Tabelle 3.2.: Digitalisierung und Codierung Bei dem Segment-orientierten Verfahren wird das Sprachsignal in Abschnitten von 10 bis 30 ms nach verschiedenen Kriterien analysiert, die u.a. die stimmhaften und stimmlosen Laute der menschlichen Sprache charakterisieren. Nach der Codierung, der Übertragung und Decodierung auf der Empfängerseite wird das Sprachsignal synthetisch mittels eines LPC-Vocoders (Linear Predictive Coding) zurückgewonnen, der akustisch den menschlichen Vokaltrakt nachbildet. Die Ausgangs-Sprachqualität wird im so genannten Meaning Opinion Score (MOS) angegeben in einer Skala von 1 = bad, 2 = poor, 3 = fair, 4 = good und 5 = excellent. 16 Im RFC 3551 wird konkret angegeben, welche Codec-Verfahren zum Einsatz kommen können.[3] 17 Für eine effiziente Übertragung von Videodaten kommen ebenfalls Codierungsverfahren zum Einsatz, auf die hier jedoch nicht weiter eingegangen wird. 3.2 Transport der digitalen Sprachdaten Zur Übertragung von Daten für Echtzeitanwendungen in datenpaketvermittelnden Netzen, wie dem Internet, sind Protokolle erforderlich, die möglichst geringe Übertragungszeiten und Isochronität, also den gleichen 16 vgl. Badach 2007, S. 133 ff. 17

8 8 zeitlichen Ablauf bei Sender und Empfänger sichern. In der Funktion wird dabei unterschieden nach Protokollen für die Datenübermittlung selbst und für die Kontrolle und Absicherung der Übermittlung bzw. der Übertragungsqualität. Bei den Transportprotokollen wird zwischen verbindungsorientierten, verbindungslosen und gemischten Protokollen unterschieden. Verbindungsorientierte Protokolle wie TCP ermöglichen eine gesicherte Übertragung, da eine virtuelle Verbindung aufgebaut wird und empfangene Daten quittiert werden. Verbindungslose Protokolle wie UDP übermitteln verbindungslos Daten und erhalten keine Bestätigung, ob diese angekommen sind. Ein Beispiel für ein gemischtes Protokoll ist das Domain Name System (DNS), das in einem nachfolgenden Kapitel kurz erläutert wird. 18 ProtokollBeschreibung RFC RTSP Real-Time Transport Streaming Protocol (Application Layer)RFC 2326 initiiert und kontrolliert einen oder mehrere zeit-synchrone Datenströme für Audio und Video. Die eigentliche Datenübertragung erfolgt meist über RTP. RTCP Real-Time Transport Control Protocol (Application Layer)RFC 3550 Da RTP keine Empfangsquittierung hat, wird als RTP Monitoringprotokoll RTCP eingesetzt, indem Reports ausgetauscht werden, um die Qualität der Sprachübermittlung zu überwachen. Real-Time Tranport Protocol (Transport Layer) zur RFC 3550, Übertragung von Sprache/Audio und Video in Echtzeit. Mit 3551 dem Dokument RTP Profile for Audio and Video Conferences with Minimal Control" (RTP A/V Profile) wird eine Hilfe gegeben zur Implementierung von Audio, Video und anderen Echtzeit-Multimediaanwendungen. Zusätzlich existieren für RTP viele Spezifikationen zur Payload (Medienformate der zu übertragenden Nutzdaten) und zur Header Compression (Reduzierung der Größe des Overhead, wie Compressed RTP (CRTP) und Robust Header Compression (ROHC)). RSVP Resource Reservation Protocol (Transport Layer) dient zurrfc 2205, Reservierung einer benötigten Bandbreite und der Ermittlung2750, 3936, der optimalen Route in IP-Netzen, um eine bestimmte 4495 Quality of Service (QoS) zu garantieren. TCP Transmission Control Protocol (Transport Layer) ermöglichtrfc 793, eine gesicherte virtuelle Verbindung zwischen zwei 3168 Rechnern über Sockets (Internetadresse und TCP-Port). UDP User Datagram Protocol (Transport Layer) ermöglicht eine RFC 768 ungesicherte Übertragung mit wenig Overhead auf dem Internet Protocol. SCTP Stream Control Transmission Protocol (Transport Layer) alsrfc 3286, verbindungsorientiertes Protokoll arbeitet ähnlich wie TCP Es werden jedoch keine sequenzierte Byte-Streams übertragen, sondern parallel mehrere Inbound- und Outbound-Streams, die Nachrichten in s.g. Chunks unidirektional an einen oder mehrere Endpunkte (IP-Adresse und SCTP-Port) transportieren. Es können z.b. Signalisierungsprotokolle wie SS7 aus dem ISDN übertragen werden und bietet einen Schutz vor Denial of Service-Attacken. IP Internet Protocol (Network/Internet Layer) dient der datenpaketvermittelnden Übertragung. Als RFC 791 Kontrollmecha-nismus ist nur die Header Checksum gegeben. Weitere Fehlerkontrollen können mit dem Internet Control Message Protocol (ICMP) durchgeführt werden. 18 vgl. Badach 2007, S. 69

9 9 Tabelle 3.3: Protokolle für die Sprachübermittlung Nachfolgend werden die Protokolle RTP und RTCP etwas näher betrachtet Real-Time Transport Protocol Eine RTP-Session kann als ein logischer Media Channel (Übermittlungskanal) verstanden werden, in dem die zu übertragenden Daten, die Payload enthalten ist. Daneben sind noch diverse Informationen im RTP-Header angegeben, die die Reihenfolge der RTP-Pakte und die Isochronität garantieren sowie die Art der Payloadformate und den Einsatz von Translator und Mixer regeln. Die Translatorfunktionalität ermöglicht die Umsetzung von einem Payloadformat in ein anderes, der Mixer kann verschiedene Quellmedien in einer Payload zusammenfassen V=2 P X CC M PT sequence number timestamp synchronization source (SSRC) identifier +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ contributing source (CSRC) identifiers (optional) header extension (optional) payload (audio/video segment) (optional) Abbildung 3.2: RTP Packet Format Die Bedeutung der einzelnen Abschnitte im RTP-Paket bzw. im RTP Header 19 [1] 20 [2] 21 : Version (V), 2 bits: RTP-Version Padding (P), 1 bit: gibt an, ob das Paketes für eine gewünschte Länge mit Bit-Oktetten aufgefüllt werden muss, wie z.b. bei Verschlüsselungen Extension (X), 1 bit: weist auf eine Header Extension CSRC count (CC), 4 bits: gibt de Anzahl der Quell-Indikatoren an - siehe CRSC-List Marker (M), 1 bit: weist auf eine anwendungsspezifische Nutzlast Payload type (PT), 7 bits: Format der Nutzlast, spezifiziert durch eine feste Nummer (0 bis 95) oder durch dyn" (96 bis 127) für eine dynamische Zuteilung in einer Session (Beispiele: 0: PCM µ/g.711, 4: G.723, 8: PCM A/G.711, 31: H.261, 34: H.263) Sequence number, 16 bits: ist eine Nummer, die zufällig ausgewählt je weiterem RTP-Paket hochgezählt wird, die Nummer kennzeichnet ein Paket und legt die Reihenfolge fest Timestamp, 32 bits: eine beliebig festgelegte Zeitmarke, die für die Synchronisation und zum Ausgleich von Jitter (Schwankungen der Übertragungszeit) verwendet wird SSRC - Synchronised Source Identifiers, 32 bits: dient zur Unterscheidung der Synchronisationsquelle, von der die Media-Daten stammen, damit der Empfänger diese richtig zuordnen kann CSRC - Contributing Source Identifiers, Liste möglich von 0 bis 15 zu je 32 bits: Angaben, wenn mehrere Mediaquellen zusammengefasst/gemixt werden Header Extension: wird optional für neue Klassen von Anwendungen, also Nutzlast abhängig verwendet Payload: enthält die eigentlichen Mediadaten 19 vgl. Badach 2007, S. 149 ff

10 10 Hier ein Beispiel für RTP-Paket aus einer RTP-Session 22 : Frame 276 (104 bytes on wire, 104 bytes captured) Ethernet II, Src: UniwillC_3e:79:8a (00:03:0d:3e:79:8a), Dst: ProcompI_fe:2b:f3 (00:30:95:fe:2b:f3) Internet Protocol, Src: ( ), Dst: eul pip.eu.verio.net ( ) User Datagram Protocol, Src Port: 5004 (5004), Dst Port: 6630 (6630) Real-Time Transport Protocol [Stream setup by SDP (frame 27)] [Setup frame: 27] [Setup Method: SDP] = Version: RFC 1889 Version (2) = Padding: False = Extension: False = Contributing source identifiers count: = Marker: False Payload type: ilbc (102) Sequence number: 5184 [Extended sequence number: 70720] Timestamp: Synchronization Source identifier: 0x35825f05 ( ) Payload: 7899AF945B63EEACF743073C3B591F00740F68B41980BEA1... Text 3.1: Beispiel RTP-Paket Das Beispiel zeigt neben dem RTP-Paket auch die umgebenden Protokollebenen UDP, IP und Ethernet mit Angaben zu den IP-Adressen und den genutzten Ports. Wie zu sehen ist, erfolgte hier ein Sprachkommunikation mit dem Internet Low Bit Rate Codec. Das Netzwerk-Analyse-Tool mit dem die VoIP-Session beobachtet wurde, zeigt an, welcher Signalisierungskanal, hier mit dem Session Description Protocol (SDP), die RTP-Session steuert Real-Time Transport Control Protocol Das RTCP hat als eine Art Reporting-Kanal für RTP verschiedene Typen von Kontrollinformationen, die als Nummern im Protokollfeld Payload Type erscheinen. Sender report - SR (200): Übertragungs- und Empfangsstatistiken der beteiligten Quellen als Information für den Empfänger, zur Einstellung auf die zu erwartende Qualität bzw. die notwendigen Ressourcen Receiver report - RR (201): Empfangsstatistik der tatsächlich empfangenen Datenqualität SR- und RR-Datenpakete nach dem RTCP haben annähernd den gleichen Aufbau. Source description - SDES (202): Quellangaben mit textuellem Namen, um Daten einzelner Quellen zusammenführen zu können. Anzeige des Endes - BYE (203) Applikationsspezifische Funktionen - APP (204) Der Anfang der RTCP-Pakete hat einen festen Teil, der ähnlich aufgebaut ist wie die RTP-Datenpakete, gefolgt von einem variablen Teil, der in jedem Fall mit einer 32-bit-Begrenzung abgeschlossen wird. Zusammengefasst können folgende Aufgaben festgehalten werden, die Überwachung der Übertragungsqualität, die Identifikation der Quelle und die Unterstützung der Mehrpunkt-Kommunikation. 23 [1] Anmerkung: aufgenommen mit Wireshark Network Protocol Analyzer 23 vgl. Badach 2007, S. 158 ff. 24

11 11 Nachfolgend exemplarisch das SR-Format des RTCP-Datenpaketes und ein RTCP-Beispiel aus einer RTP-Session, wobei, wie schon gesagt, schon einige Angaben in RTP-Paketen enthalten sind. Angegeben sind in dem Paket unter anderem die Anzahl der Report-Blöcke - Reception report count (RC), die Länge des RTCP-Paketes - length, ein Zeitstempel im Format Network Time Protocol (NTP). Besonders wichtig ist der Pakettyp - PT, mit dem der jeweilige oben genannte Typ angegeben wird. Daneben gibt es noch weitere hier nicht weiter genannte Typen.[2] 25 Im Report-Block sind noch eine Abschätzung des Jitters, eine Verlustquote von RTP-Paketen, der Fraction Lost und eine Berechnung der Verzögerung, dem Round-Trip Delay header V=2 P RC PT=SR=200 length SSRC of sender +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ sender NTP timestamp, most significant word info NTP timestamp, least significant word RTP timestamp sender's packet count sender's octet count +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report SSRC_1 (SSRC of first source) block 1 fraction lost cumulative number of packets lost extended highest sequence number received interarrival jitter last SR (LSR) delay since last SR (DLSR) +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report SSRC_2 (SSRC of second source) block 2 :... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ profile-specific extensions Abbildung 3.3: RTCP-Packet Sender Report SR Im nachfolgenden Beispiel ist die Ähnlichkeit des RTCP-Paketes mit dem RTP-Paket zu sehen. 26 Frame 146 (122 bytes on wire, 122 bytes captured) Ethernet II, Src: UniwillC_3e:79:8a (00:03:0d:3e:79:8a), Dst: ProcompI_fe:2b:f3 (00:30:95:fe:2b:f3) Internet Protocol, Src: ( ), Dst: eul pip.eu.verio.net ( ) User Datagram Protocol, Src Port: 5005 (5005), Dst Port: 6631 (6631) Real-time Transport Control Protocol (Sender Report) [Stream setup by SDP (frame 27)] [Setup frame: 27] [Setup Method: SDP] = Version: RFC 1889 Version (2) = Padding: False = Reception report count: Anmerkung: aufgenommen mit Wireshark Network Protocol Analyzer

12 12 Packet type: Sender Report (200) Length: 12 (52 bytes) Sender SSRC: 0x35825f05 ( ) Timestamp, MSW: (0xcae47d13) Timestamp, LSW: (0x ) [MSW and LSW as NTP timestamp: Nov 13, :44:19,5938 UTC] RTP timestamp: Sender's packet count: 68 Sender's octet count: 3400 Source 1 Identifier: 0x (0) SSRC contents Extended highest sequence number received: 0 Interarrival jitter: 0 Last SR timestamp: 0 (0x ) Delay since last SR timestamp: 0 (0 milliseconds) Real-time Transport Control Protocol (Source description) [Stream setup by SDP (frame 27)] [Setup frame: 27] [Setup Method: SDP] = Version: RFC 1889 Version (2) = Padding: False = Source count: 1 Packet type: Source description (202) Length: 6 (28 bytes) Chunk 1, SSRC/CSRC 0x35825F05 Identifier: 0x35825f05 ( ) SDES items Type: CNAME (user and domain) (1) Length: 17 Text: user@gizmoproject Type: END (0) [RTCP frame length check: OK - 80 bytes] Text 3.2: Beispiel RTCP-Packet SR 3.3 Protokolle zur Signalisierung Das Session Initiation Protocol hat für VoIP gegenüber dem Rahmenwerk H.323-SIG in den letzten Jahren eindeutig die größere Bedeutung gewonnen. Daneben kommt es auch zunehmend in den neueren Ansätzen Next Generation Network und IP Multimedia Subsystem zum Einsatz, so dass nur SIP ausführlicher dargestellt werden soll. Protokoll Beschreibung RFC/ITU H.323-SIGH ITU-T Recommendation Q.931 H.323 beschreibth.323 H H H.245 das Zusammenwirken der Protokolle H.225.0, H.245 sowieh.245 Q.931 RTP und RTCP. H entspricht der Schicht 2, also SIP der Sicherungsschicht des D-Kanal-Protokolls im ISDN und wird über TCP geführt. H beschreibt die Rufsignalisierung, die Medien (Audio und Video), die Umwandlung des Datenstroms in Pakete, die Synchronisierung des Datenstroms und die Kontrolle des Nachrichtenformats. H.245 beschreibt die Nachrichten und Verfahrensweisen für das Öffnen und Schließen logischer Kanäle, die zur Übertragung von Audio, Video und Daten dienen; sowie den Austausch, die Kontrolle und Anzeige der Übertragungskapazitäten.[1] 27 Session Initiation Protocol (Application Layer) SIP ist ein textbasierendes Protokoll ähnlich dem Hypertext RFC 3261 bis 3265, 3853, Transfer Protokoll (HTTP). In der Funktion entspricht SIP4320,

13 13 weitgehend dem D-Kanal-Protokoll im ISDN und kann beliebige RTP-Sessions für beliebige Multimediaströme mit einem oder mehreren Teilnehmern verwalten und scheint sich zum Standard-Protokoll für Voice over IP SDP (VoIP) zu entwickeln. 28 [2] 29 RFC 4566 Session Desciption Protocol (Application Layer) SIP wird unterstützt durch das Session Desciption Protocol (SDP) zur Beschreibung von Multimediaströmen. 30 Tabelle 3.4.: Protokolle zur Signalisierung Session Initiation Protocol Die Signalisierung dient dem Auf- und Abbau und der Steuerung einer Verbindung. Eine SIP-Session stellt damit einen logischen Kanal dar, der zusätzlich über eine Fehlerkontrolle verfügt, so dass im Regelfall auf UDP aufgesetzt und hierdurch ein schneller Verbindungsaufbau erreicht werden kann. Als Well-Known-Port wird 5060 angegeben. Häufig werden jedoch auch andere Ports benutzt, da vielen Netzwerken eine Firewall bzw. Network Adress Translation (NAT) vorgeschaltet ist, die ggf. diesen Port sperren oder umleiten. Die Übertragung der Nutzinformation erfolgt, wie bereits dargestellt in RTP-Paketen. Es ist zusätzlich notwendig zwischen den Endgeräten der Kommunikation bekannt zu geben, welcher Art die Nutzinformation sind. Dies erfolgt mit dem Session Description Protocol (SDP). Die Endpunkte der Kommunikation bezeichnet man, nach der Client-Server-Systematik als User Agent Client (UAC) für die aufrufende Seite und User Agent Server (UAS) für die aufgerufene Seite. Der große Vorteil von SIP besteht darin, dass es sich in die bestehende, durch HTTP geprägte Landschaft einfügt. So erfolgt die Adressierung für einen Anruf mittels eines URI (Uniform Ressource Identifier), der Teilnehmer entspricht der -Adress-Systematik z.b. oder im Sinne einer Rufnummer (SIP URI). Die IP-Adresse des zugeordneten Endgerätes kann somit auch über DNS ermittelt werden. Neben dem Einsatz für den direkten Verbindungsaufbau zwischen zwei Endpunkten, soweit die IP-Adresse bekannt ist, wird SIP auch für die Signalisierung mit Hilfe von Proxy-Servern, Redirect-Servern und Registraren/Location-Servern verwendet. 31 [1] SIP Proxy-Mode und Redirect-Mode Die beiden Betriebsarten Proxy-Mode und Redirect-Mode ermöglichen es, ohne direkte Kenntnis der IP-Adresse des gewünschten Endgerätes, eine Verbindung aufzubauen. Der Proxy-Server leitet, ggf. mit Nachfrage bei einem Location-Server die Anfrage (INVITE) des Anrufers an das entsprechende Endgerät oder an einen anderen Proxy-Server. Es erfolgt also eine Weiterleitung der Anfrage. Der Austausch der Echtzeitdaten über RTP erfolgt dann direkt zwischen den Endgeräten (peer-to-peer), wenn der Anruf akzeptiert (OK) und die Verbindung aufgenommen (ACK) wurde. Der Abbau (BYE) der Verbindung, für den ebenfalls der Proxy-Server benutzt wird, wird abschließend quittiert (ACK). Im Redirect-Mode ermittelt der Redirect-Server die SIP-Adresse des gewünschten Partners und teilt diese dem anrufenden Endgerät mit. Der Verbindungsaufbau und die Signalisierungsmeldungen (Request und Response genannt) genannt, erfolgt danach direkt zwischen den Endpunkten. 28 vgl. Badach 2007, S vgl. ebd., S. 248 f. 31 vgl. Badach 2007, S. 247 ff. 32

14 14 Mit diesen Mechanismen können Rufverzweigungen, Anrufweiterleitungen und die Einbindung von netzseitigen Diensten wie Voic -Systeme eingerichtet werden. Daneben gibt es noch zwei weitere wichtige Servertypen, die VoIP-Gateways für den Übergang von IP-Netzen auf ISDN und die Gatekeeper zwischen Netzen mit SIP und H.323-Signalisierung, wo ggf. auch die Konvertierung der Nutzdaten in ein anderes Medienformat stattfindet SIP-Nachrichten SIP-Nachrichten verfügen wie HTTP über einen Satz an Request-Typen und Response-Klassen, mit denen die Abläufe gesteuert werden. Request-Typen Response-Klassen INVITE initiiert einen neuen Anruf und enthältinformational - 1xx teilt dem SIP-Adresse von beiden Teilnehmern, den Absender die Bearbeitung des Grund (Subject) des Anrufes und dessen Requests mit: 100 Trying, 180 Priorität. Ringing BYE initiiert den Abbau der bestehenden Success - 2xx teilt dem Absender VoIP-Verbindung den erfolgreichen Empfang mit: 200 OK ACK (ACKnowledgemanagement) bestätigt die Annahme des Anrufes OPTIONS fragt nach Fähigkeiten (Media Capabilities), wie Arten von Medien (Audio, Redirection - 3xx signalisiert dem Absender, dass der Empfänger sich in einer anderen Domäne befindet: 301 Moved Permanently, 302 Moved Temporarily Client-Error - 4xx teilt dem Absender ein Problem bei der Video) und Verfahren zur Codierung Bearbeitung des Requests mit: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 406 Not Acceptable, 486 Busy Here CANCEL bricht Aufbau einer be-reits initiiertenserver-error - 5xx signalisiert dem VoIP-Verbindung ab Absender ein Serverproblem: 500 Internal Server Error, 501 Not Implemented, 502 Bad Gateway, 505 SIP Version not supported REGISTER teilt Registrar Informationen über Global-Failure - 6xx signalisiert ein die Lokation/Art der IP-Telefone mit; Registrarallgemeines Zugriffsproblem: 600 Busy Everywhere, 606 Not Acceptable kann im SIP Server (Proxy bzw. Redirect-Server) oder im Location-Server untergebracht werden INFO übermitteln zusätzlicher Informationen während einer bestehenden RTP-Session PRACK (Provisional Response ACKnowledgement) bestätigen eines Responses mit vorläufigen Charakter (sog. Provisional Responses) wie z.b. 180 Ringing, um eine Übertragung zu garantieren UPDATE verändert bestimmte Parameter schon während des Aufbaus dieser RTP-Session MESSAGE spezifiziert die SIP-Erweiterungen für Instant Messaging 33 vgl. Badach 2007, S. 252 ff.

15 15 REFER soll sog. Session Transfer (überleiten von einer Verbindung in eine andere) zu ermöglichen SUBSCRIBE und NOTIFY übermitteln bestimmter Ereignisse z.b. die Integration des Internets mit dem Intelligent Network Tabelle 3.5: SIP Request-Typen und Response-Klassen Exemplarisch ist der Verlauf einer Verbindung im RFC 3261 dargestellt, die über zwei Proxy-Server abläuft. Request und Response werden jeweils von den Proxy-Servern empfangen und weitergeleitet. Die Verbindung wird von Alice" initiiert und in diesem Fall von Bob" beendet. Media Session steht für den RTP-Datenaustausch. atlanta.com... biloxi.com. proxy proxy... Alice's Bob's softphone SIP Phone INVITE F > INVITE F2 100 Trying F > INVITE F4 < Trying F > < Ringing F6 180 Ringing F7 < Ringing F8 < OK F9 < OK F10 < OK F11 < < ACK F > Media Session <================================================> BYE F13 < OK F > Abbildung 3.4: SIP-Session über zwei Proxy-Server In dem nachfolgenden Beispiel einer reale SIP-Session1 ist zu sehen, dass in dem INVITE-Request auch das Session Descripten Protocol zum Einsatz kommt. Dort ist angegeben, welche Medienformate auf Seiten des Anrufenden verwendet werden können. In einer nachfolgenden Antwort OK-Response des Empfängers, die hier nur auszugsweise angegeben ist, wird mitgeteilt welche Möglichkeiten der Empfänger hat, so dass ein passendes Format gewählt werden kann. In diesem Fall ist es, wie in der obigen RTP-Session zu sehen ist, der Codec ilbc (Internet Low Bit Rate codec). An dem Beispiel ist auch der Aufbau eines SIP-Paketes zu erkennen, u.a. mit der Angabe des Request- bzw. Response-Typen, des Empfängers (To), des Senders (From) und des Inhaltes (Content-Type) mit Verweis auf das SDP-Paket. Weitere Informationen, wie in diesem Fall zu einer anbieterspezifischen Chat-Funktion mit dem Jabber Protocol, können enthalten sein. Im Teil des UDP-Protocols ist auch der angesprochene Port 5060 zu sehen User Datagram Protocol, Src Port: (64064), '''Dst Port: 5060 (5060)''' Session Initiation Protocol Request-Line: '''INVITE''' sip:echoproxy01.sipphone.com SIP/2.0 Method: INVITE [Resent Packet: False] 34 Anmerkung: aufgenommen mit Wireshark Network Protocol Analyzer

16 16 Message Header Via: SIP/2.0/UDP :64064;branch=z9hG4bK-d e49d de51-1--d87543-;rport Max-Forwards: 70 Contact: <sip: :64064> To: <sip:echoproxy01.sipphone.com> From: <sip: proxy01.sipphone.com>;tag=1f0e7842 Call-ID: 720ac62d Tm90ZWJvb2tfQW1pbG8. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, INFO, NOTIFY, MESSAGE Content-Type: application/sdp Supported: ICE User-Agent: WinGizmo/ (Gizmo-s2n1) Content-Length: 451 JabberID: name-xychat.gizmoproject.com CQBM: 242 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): GizmoProject IN IP Session Name (s): GizmoAudioSession Connection Information (c): IN IP Time Description, active time (t): 0 0 Media Description, name and address (m): audio 6630 RTP/AVP Media Attribute (a): rtpmap:103 ISAC/16000 Media Attribute (a): rtpmap:102 ilbc/8000 Media Attribute (a): rtpmap:97 IPCMWB/16000 Media Attribute (a): rtpmap:100 EG711U/8000 Media Attribute (a): rtpmap:101 EG711A/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:106 telephone-event/8000 Media Attribute (a): rtpmap:13 CN/8000 Media Attribute (a): rtpmap:117 red/8000 Media Attribute (a): rtcp: Session Initiation Protocol Status-Line: SIP/ OK... Message body Session Description Protocol... Time Description, active time (t): 0 0 Media Description, name and address (m): audio RTP/AVP Media Attribute (a): rtpmap:102 ilbc/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:106 telephone-event/8000 Media Attribute (a): fmtp: Media Attribute (a): silencesupp:off Text 3.3: Beispiel SIP INVITE-Request und OK-Request mit SDP 3.4 Ablaufsteuerung zwischen verschiedenen Netzen Neben dem Verbindungsaufbau und dem Transport der Nutzdaten ist eine Ablaufsteuerung auf der Ebene der Verbindungen unterschiedlicher Netze notwendig. Dies wird im Zusammenspiel von VoIP-Netzen und anderen Netzen mit Hilfe der Protokolle Media Gateway Control Protocol (MGCP) und Media Gateway Control (Megaco) ermöglicht.

17 17 Protokoll Beschreibung RFC/ITU MGCP Media Gateway Control Protocol (Application Layer) MGCP ist ein Netzwerkprotokoll zur Steuerung von RFC 3435, 3661 VoIP-Gateways. MGCP ist ein Master/Slave Protokoll welches die Steuerinformationen in Klartext (wie SIP) überträgt. Das VoIP-Gateway arbeitet als Slave und wird von einer Vermittlungseinheit (Call Control Device) Megaco gesteuert.[1] 35 Die Übertragung erfolgt auf Basis von UDP. Media Gateway Control (Application Layer) Megaco ist RFC 3015, ein von der IETF und der ITU-T unterstütztes Gate- 2805, H.248 way-protokoll zur Steuerung von Media Gateways (MG) und wird für den Aufbau von VoIP-Verbindungen benutzt. Es arbeitet unabhängig von Rufsignalisierungen wie dem Netzwerkprotokoll H.323 und dem SIP-Protokoll.[2] 36 Es kann über TCP und UDP übertragen werden. Tabelle 3.6: Protokolle zur Ablaufsteuerung zwischen Netzen Wegen des größeren Funktionsumfangs und der höheren Akzeptanz durch die Standardisierung von ITU-T und IETF kommt das Protokoll Megaco stärker zum Einsatz, insbesondere für das Next Generation Network und das IP Multimedia Subsystem. MGCP wird eher in kleineren Netzinfrastrukturen, z.b. zur Anbindung von TK-Anlagen genutzt. 37 Die zentralen Elemente zur Verknüpfung und Ablaufsteuerung sind das Media Gateway (MG) und der Media Gateway Controller (MGC). Das Media Gateway bildet die Schnittstelle zwischen dem IP-Netzwerk und anderen Netzwerken, wie dem herkömmlichen Telefonnetz (public switched telephone network - PSTN). Dort erfolgt nur die Umsetzung der angelieferten Nutzdaten in die für das jeweilige Netz transportierbare Form - für VoIP in RTP/RTCP-Pakete. Der MGC übernimmt die Steuerung der MG und die Signalisierung, also die Umsetzung von und nach SIP bzw. H.323-SIG. Zwischen MG und MGC kommen die Protokolle MGCP und Megaco zum Einsatz. Für die Wandlung der Signalisierung zwischen den Netzen wird analog zum MG ein Signaling Gateway (SG) benötigt, dessen Daten z.b. mittels SIGTRAN-Protokollen 38, wie das bereits oben erwähnte Transportprotokoll SCTP, an das MGC gegeben werden. Einen Überblick gibt folgendes Bild[3] 39 : vgl. Badach 2007, S. 287 ff. 38 SIGTRAN: IETF Working Group, die sich mit Signalisierung von und zu PSTN beschäftigt 39

18 18 Abbildung 3.5: Überblick Konvergente Netzwerkarchitektur 3.5 Telefonnummern-Systematik und Internet-Adressierung Das Grundprinzip der meisten Anbieter für VoIP-Dienste ist, für angemeldete Nutzer die zentrale Vermittlung unter den Nutzern durchzuführen. Eine direkte Verbindung von Nutzern unterschiedlicher Anbieter ist in der Regel nicht gegeben. Die Bereitstellung eines unabhängigen Verzeichnisdienstes mit dem ENUM-System (TElephone NUmber Mapping) in Verbindung mit dem Domain Name Service (DNS) ermöglicht es dem einzelnen Nutzer allgemein erreichbar zu werden und so unabhängig von einem Anbieter verschiedene Dienste wie VoIP mittels SIP mit anderen Nutzern zu betreiben. ProtokollBeschreibung RFC/ITU DNS Domain Name System (Application Layer) DNS wird hauptsächlich zur Umsetzung von Domain-Namen in RFC 1034, 1035 IP-Adressen (forward lookup) genutzt. Eine umgekehrte Abfrage ist ebenso möglich (reverse lookup). Das DNS besteht aus den drei Hauptkomponenten Domain-Namensraum, Nameserver und Resolver. Das DNS stellt ein hierarchisches System dar, das sich von hinten gelesen in den Ebenen eines Domain-Namens spiegelt (z.b. tools.ietf.org). Die erste Ebene des Domain-Namens (.arpa,.com,.org,.de,...) wird als Top-Level-Domain ENUM bezeichnet.[1] 40 TElephone NUmber Mapping ist die Abbildung von RFC 3761 herkömmlichen Telefonnummern nach dem ITU-T-System (3401) E.164 auf IP-Adressen. Es nutzt das Domain Name SystemE.164 (DNS) um E.164-Nummern zu speichern und ist in der Lage, Dienste zu kennzeichnen, die unter einer E.164-Nummer 40

19 19 möglich sind. Es ermöglicht damit als Verzeichnisdienst die Verbindung von VoIP-Nutzern mit Nutzern anderer Netze. ENUM ist jedoch keine VoIP-Funktion und sollte getrennt von deren Protokollen betrachtet werden.[2] 41 [3] 42 Der Dienst wird auf Servern unterhalb der Top Level Domain.arpa betrieben. Tabelle 3.7: Zuordnung IP-Adress mit Telefonnummer Die folgende Darstellung soll nur kurz anreißen, wie und welche Daten in dem Verzeichnisdienst vorgehalten werden können. Beispiel aus dem RFC 3761: Die Rufnummer " " wird zu: e164.arpa. Der ENUM-DNS stellt Server bereit, auf denen Naming Authority Pointer (NAPTR) im DNS Resource Record gespeichert sind. Es werden auf die umgeformte E.164-Rufnummer die verfügbaren Internet-Dienste abgebildet. $ORIGIN e164.arpa. NAPTR "u" "E2U+sip" NAPTR "u" "E2U+h323" NAPTR "u" "E2U+msg" NAPTR "u" "E2U+tel" "!^.*$!tel: !". Folgendes wird damit beschrieben: Die Domain e164.arpa. ermöglicht eine Kommunikation mittels SIP, H.323 für Sprache und SMTP für . Die Kürzel "sip", "h323", "msg" und tel" haben hierbei keinen direkten Bezug zu den Protokollen oder zum URI-Schema

20 4 Schlussbetrachtung 20 4 Schlussbetrachtung Bis zu diesem Punkt wurden im Wesentlichen die Grundlagen für VoIP dargestellt, die ein Grundverständnis für die Abläufe und Inhalte der verwendeten Protokolle erreichen soll. Weiterführende Themen seien an dieser Stelle nur in Schlagworten für VoIP benannt. Sicherheit (Technik und Datenschutz) Programmierschnittstellen und -umgebungen, u.a. auf Basis von Java Netzkonzepte Next Generation Network und IP Multimedia Subsystem Endgeräte und Anwendungen: Hardware und Softphones Anbieter von VoIP-Diensten und Hardware für Privat- und Geschäftskunden Marktübersichten und Geschäftsmodelle Technikfolgen wirtschaftlicher und sozialer Art VoIP ist technisch gesehen noch immer ein spannendes Thema, obwohl inzwischen die Grundlagen gefestigt und standardisiert sind. Auf Basis von VoIP und mit VoIP als einem Bestandteil neben Instand Messaging, IP-TV, usw. entwickeln sich heute neue Angebote, die schnell, wegen der hohen Verfügbarkeit von Internetzugängen, Verbreitung finden. Die Einbindung von VoIP in eigene Applikationen und Angebote stellt für jeden Programmierer ein interessantes und ggf. lukratives Betätigungsfeld dar.

21 5 Literaturverzeichnis und Web-Links 21 5 Literaturverzeichnis und Web-Links Badach, Anatol (2007): Voice over IP Die Technik. 3., erweiterte Auflage. München Wien: Carl Hauser Verlag Internet Engineering Task Force (IETF): IETF Tools, insbesondere RFC: International Telecommunication Union - Telecommunication Standardization Sector (ITU-T): European Telecommunication Standards Institute(ETSI): Wikipedia, englische Version: Wikipedia, deutsche Version: Global IP Telecommunications, Inc.: Wireshark network protocol analyzer: Network Sorcery, RFC Sourcebook: Syrus:

22 6 VoIP Diensteanbieter 22 6 VoIP Diensteanbieter Anbieter Hompage Anwendung Skype Gizmo T-Online SparVoIP LowRateVoIP Google Talk Anbieter Peter zahlt Gelbe Seiten Marcophone Hompage Anmerkung Web-Initated Call Services: GoYellow Direktverbindung - Click-and-Call Joke-Anwendung

23 7 Anlagen 23 7 Anlagen Hier einige Screenshots der VoIP-Applikationen verschiedener Anbieter mit einigen Verbindungsprotokollen. Skype skype_080107_uni_1_sessions.txt (Verbindung zu einem anderen Skype-Nutzer)) Skype Kontakte: Skype Wähltasten: Skype Optionen: T-Online t-online080107_uni_2_sessions.txt (Verbindung zu einer Rufnummer an einem Telefonanschluß)

24 7 Anlagen 24 t-online-gizmo080103_sessions.txt (Verbindung zu einer Rufnummer bei einem anderen VoIP-Anbieter) T-Online Softphone (veränderbares Design): Peter zahlt Peter zahlt Anwahlseite: Gelbe Seiten Gelbe Seiten Anwahlseite: marcophon

25 7 Anlagen 25 marcophon Eingabeseite: