Inhaltsverzeichnis - Universität Osnabrück
Werbung
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 2 Entstehung und Organisationen.............................................................................................................. 3 3 Protokolle und Standards im Überblick.................................................................................................. 3.1 Digitalisierung und Codierung............................................................................................................ 3.2 Transport der digitalen Sprachdaten.................................................................................................. 3.2.1 Real-Time Transport Protocol................................................................................................... 3.2.2 Real-Time Transport Control Protocol...................................................................................... 3.3 Protokolle zur Signalisierung............................................................................................................. 3.3.1 Session Initiation Protocol........................................................................................................ 3.3.2 SIP Proxy-Mode und Redirect-Mode........................................................................................ 3.3.3 SIP-Nachrichten....................................................................................................................... 3.4 Ablaufsteuerung zwischen verschiedenen Netzen............................................................................ 3.5 Telefonnummern-Systematik und Internet-Adressierung................................................................... 5 6 7 9 10 12 13 13 14 16 18 4 Schlussbetrachtung.................................................................................................................................. 20 5 Literaturverzeichnis und Web-Links........................................................................................................ 21 6 VoIP Diensteanbieter................................................................................................................................. 22 7 Anlagen...................................................................................................................................................... 23 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. 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 1 Research Projects Agency Network), dem Vorfahrendes Internets, mittels Network Voice Protocol (NVP) [1] , 2 das 1973 entwickelt und 1977 in dem Request for Comments 741 (RFC 741) [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. 1980 (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]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.1912.5 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 1 http://en.wikipedia.org/wiki/Network_Voice_Protocol 2 http://tools.ietf.org/html/rfc741 3 http://tools.ietf.org/html/rfc768 4 http://tools.ietf.org/html/rfc791 5 http://tools.ietf.org/html/rfc793 2 Entstehung und Organisationen 4 Telekommunikationsunternehmen folgten. Als Signalisierungs-Protokoll kommt hier seit dem vor allem SIP 6 zum Einsatz. [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, Email, 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 8 - heraus gibt. Die Arbeiten werden in so genannten Working Groups durchgeführt. • International Telecommunication Union, mit der Abteilung Telecommunication Standardization Sector 9 (ITU-T) , 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. 6 http://de.wikipedia.org/wiki/VoIP 7 http://www.ietf.org/ 8 weiteres zur Organisation IETF in 'The TAO of IETF', http://tools.ietf.org/html/rfc4677 9 http://www.itu.int/ITU-T 10 http://www.etsi.org/ 3 Protokolle und Standards im Überblick 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 11 gegeben sein. Die wichtigsten Parameter der Quality of Service (QoS), die die Isochronität beeinflussen sind : • 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 12 für VoIP in einem Bild, die die Beziehungen und Abhängigkeiten veranschaulichen. 11 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. 3 Protokolle und Standards im Überblick 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 13 Schichten kurz beschrieben.[1] TCP/IP model - DoD model 4. Application layer/ Die Anwendungsschicht umfasst alle Protokolle, die mit Process layer Anwendungsprogrammen zusammenarbeiten und die Netzwerkinfrastruktur für den Austausch anwendungsspezifischer Daten nutzen. 3. Transport layer/ Die Transportschicht stellt eine Ende-zu-Ende-Verbindung host-to-host layer (host to host) her. 2. Network layer/ Die Vermittlungsschicht ist für die Weitervermittlung von Internet layer Paketen und die Wegewahl (Routing) zuständig. Auf dieser 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. 1. Network access Die Netzwerkschicht ist im TCP/IP-Referenzmodell layer 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 802.11 (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. 14 Übersicht der wichtigsten internationalen CODEC Spezifikationen [1] [2] Codec G.711 Name 15 Transfer Rate Frequency Quality / MOS Pulse Code Modulation (PCM)\ 56 o. 64 kbit/s 300 bis ISDN / 4.3 A-law and µ-law (a) 3400 Hz 13 http://en.wikipedia.org/wiki/TCP/IP_mode 14 http://www.itu.int/rec/T-REC-G/e 15 http://www.xten.de/ 3 Protokolle und Standards im Überblick 7 G.726 Adaptive Differential Pulse Code 16 - 40 kbit/s Modulation (ADPCM) (a) G.728 Low Delay Code Excited Linear 16 kbit/s Prediction (LD-CELP) (b) G.729/ Conjugate Structure Algebraic 8 kbit/s G.729A Code Excited Linear Prediction (CS-ACELP) (b) G.723.1 Multiple Maximum Likelihood 6,3 kbit/s Quantization (MPMLQ) (b) G.723 Algebraic Code Excited Linear 5,3 kbit/s Prediction (ACELP) (b) Speex Free patent audio compression 4 - 15 kbit/s Narrow-band (free), \ Code Excited Linear Prediction (CELP) (b) Speex\\\ Free patent audio compression 10 - 28 kbit/s Wide-band (free), \ Code Excited Linear Prediction (CELP) (b) DVI4 Adaptive Differential Pulse Code 32 kbit/s Modulation (ADPCM) (a) iLBC Internet Low Bit Rate Codec 13,3 kbit/s (free) (b) G.722.1 MLT 24 kbit/s l16 PCM Linear PCM at 16 bits per 128 kbit/s sample (a) EVCR Enhanced Variable Rate Codec, 8 kbit/s Relaxed Code Excited Linear Prediction (RCELP) (b) H.263 Videocodec Discrete Cosine 16-256 kbit/s Transformation (DCT) H.261 Videocodec DCT 64-256 kbit/s - / 3.8 300 bis 3400 Hz 300 bis 3400 Hz nearly ISDN / 3.6 / 3.9, 3.7 300 bis 3400 Hz - / 3.9 8 kHz medial GSM / 3.6 16 - 32 kHz better GSM 8 kHz - 8 kHz / 4.1 16 kHz - - - - - medium - 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 16 1 = bad, 2 = poor, 3 = fair, 4 = good und 5 = excellent. 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 http://tools.ietf.org/html/rfc3551 3 Protokolle und Standards im Überblick 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 18 kurz erläutert wird. Protokoll Beschreibung 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 Monitoringprotokoll RTCP eingesetzt, indem Reports ausgetauscht werden, um die Qualität der Sprachübermittlung zu überwachen. RTP 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 zur RFC 2205, Reservierung einer benötigten Bandbreite und der Ermittlung 2750, 3936, der optimalen Route in IP-Netzen, um eine bestimmte 4495 Quality of Service (QoS) zu garantieren. TCP Transmission Control Protocol (Transport Layer) ermöglicht RFC 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) als RFC 3286, verbindungsorientiertes Protokoll arbeitet ähnlich wie TCP. 4960 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 RFC 791 datenpaketvermittelnden Übertragung. Als 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 3 Protokolle und Standards im Überblick 9 Tabelle 3.3: Protokolle für die Sprachübermittlung Nachfolgend werden die Protokolle RTP und RTCP etwas näher betrachtet. 3.2.1 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. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 19 20 21 Die Bedeutung der einzelnen Abschnitte im RTP-Paket bzw. im RTP Header [1] [2] : • 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. 20 http://tools.ietf.org/html/rfc3550 21 http://tools.ietf.org/html/rfc3551 3 Protokolle und Standards im Überblick 10 22 Hier ein Beispiel für RTP-Paket aus einer RTP-Session : 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: 192.168.62.51 (192.168.62.51), Dst: eul0300290-pip.eu.verio.net (213.198.65.201) 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] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 .... = Extension: False .... 0000 = Contributing source identifiers count: 0 0... .... = Marker: False Payload type: iLBC (102) Sequence number: 5184 [Extended sequence number: 70720] Timestamp: 1682251140 Synchronization Source identifier: 0x35825f05 (897736453) 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. 3.2.2 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, 23 die Identifikation der Quelle und die Unterstützung der Mehrpunkt-Kommunikation. 22 Anmerkung: aufgenommen mit Wireshark Network Protocol Analyzer 23 vgl. Badach 2007, S. 158 ff. 24 http://tools.ietf.org/html/rfc3550 [1] 24 3 Protokolle und Standards im Überblick 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 sender info report block 1 report block 2 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| RC | PT=SR=200 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | NTP timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 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. 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: 192.168.62.51 (192.168.62.51), Dst: eul0300290-pip.eu.verio.net (213.198.65.201) 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] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0001 = Reception report count: 1 25 http://www.networksorcery.com/enp/protocol/rtcp.htm 26 Anmerkung: aufgenommen mit Wireshark Network Protocol Analyzer 26 3 Protokolle und Standards im Überblick 12 Packet type: Sender Report (200) Length: 12 (52 bytes) Sender SSRC: 0x35825f05 (897736453) Timestamp, MSW: 3403971859 (0xcae47d13) Timestamp, LSW: 2550136832 (0x98000000) [MSW and LSW as NTP timestamp: Nov 13, 2007 19:44:19,5938 UTC] RTP timestamp: 1682220110 Sender's packet count: 68 Sender's octet count: 3400 Source 1 Identifier: 0x00000000 (0) SSRC contents Extended highest sequence number received: 0 Interarrival jitter: 0 Last SR timestamp: 0 (0x00000000) 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] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0001 = Source count: 1 Packet type: Source description (202) Length: 6 (28 bytes) Chunk 1, SSRC/CSRC 0x35825F05 Identifier: 0x35825f05 (897736453) 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-SIG H.323 - ITU-T Recommendation Q.931 H.323 beschreibt H.323 H.225.0 H.225.0 das Zusammenwirken der Protokolle H.225.0, H.245 sowie H.245 Q.931 H.245 RTP und RTCP. H.225.0 entspricht der Schicht 2, also der Sicherungsschicht des D-Kanal-Protokolls im ISDN und wird über TCP geführt. H.225.0 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 27 SIP und Anzeige der Übertragungskapazitäten.[1] Session Initiation Protocol (Application Layer) SIP ist RFC 3261 bis ein textbasierendes Protokoll ähnlich dem Hypertext 3265, 3853, Transfer Protokoll (HTTP). In der Funktion entspricht SIP 4320, 4916 27 http://de.wikipedia.org/wiki/H.323 3 Protokolle und Standards im Überblick 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 28 SDP 29 (VoIP) zu entwickeln. [2] Session Desciption Protocol (Application Layer) SIP wird RFC 4566 unterstützt durch das Session Desciption Protocol (SDP) zur Beschreibung von Multimediaströmen. 30 Tabelle 3.4.: Protokolle zur Signalisierung 3.3.1 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 Email-Adress-Systematik z.B. [email protected] oder im Sinne einer Rufnummer [email protected] (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, 31 Redirect-Servern und Registraren/Location-Servern verwendet. [1] 32 3.3.2 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. 248 29 http://de.wikipedia.org/wiki/Session_Initiation_Protocol 30 vgl. ebd., S. 248 f. 31 vgl. Badach 2007, S. 247 ff. 32 http://tools.ietf.org/html/rfc3261 3 Protokolle und Standards im Überblick 14 Mit diesen Mechanismen können Rufverzweigungen, Anrufweiterleitungen und die Einbindung von netzseitigen Diensten wie Voice-Mail-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 33 stattfindet. 3.3.3 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ält Informational - 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 Redirection - 3xx signalisiert dem die Annahme des Anrufes Absender , dass der Empfänger sich in einer anderen Domäne befindet: 301 Moved Permanently, 302 Moved Temporarily OPTIONS fragt nach Fähigkeiten (Media Client-Error - 4xx teilt dem Capabilities), wie Arten von Medien (Audio, 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 initiierten Server-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; Registrar allgemeines Zugriffsproblem: 600 kann im SIP Server (Proxy bzw. Busy Everywhere, 606 Not Redirect-Server) oder im Location-Server Acceptable 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. 3 Protokolle und Standards im Überblick 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 proxy . . . biloxi.com proxy . . . Alice's . . . . . . . . . . . . . . . . . . . . Bob's softphone SIP Phone | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | |------------------------------------------------->| | | 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 34 zu sehen. ... User Datagram Protocol, Src Port: 64064 (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 3 Protokolle und Standards im Überblick 16 Message Header Via: SIP/2.0/UDP 192.168.62.51:64064;branch=z9hG4bK-d87543-2e49d2507207de51-1--d87543-;rport Max-Forwards: 70 Contact: <sip:1747246242787.183.76.234:64064> To: <sip:echoproxy01.sipphone.com> From: <sip:17472462427proxy01.sipphone.com>;tag=1f0e7842 Call-ID: 720ac62d7247393712839456656Tm90ZWJvb2tfQW1pbG8. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, INFO, NOTIFY, MESSAGE Content-Type: application/sdp Supported: ICE User-Agent: WinGizmo/1.7.08 (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 1120482861 1 IN IP4 213.198.65.201 Session Name (s): GizmoAudioSession Connection Information (c): IN IP4 213.198.65.201 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 6630 RTP/AVP 103 102 97 100 101 0 8 3 106 13 117 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:6631 -------------------------------------------------------------------------... Session Initiation Protocol Status-Line: SIP/2.0 200 OK ... Message body Session Description Protocol ... Time Description, active time (t): 0 0 Media Description, name and address (m): audio 19566 RTP/AVP 102 0 8 106 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:106 0-16 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. 3 Protokolle und Standards im Überblick 17 Protokoll Beschreibung RFC/ITU MGCP Media Gateway Control Protocol (Application Layer) RFC 3435, MGCP ist ein Netzwerkprotokoll zur Steuerung von 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) 35 gesteuert.[1] Die Übertragung erfolgt auf Basis von UDP. Megaco Media Gateway Control (Application Layer) Megaco ist RFC 3015, ein von der IETF und der ITU-T unterstütztes Gate2805, 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] kann über TCP und UDP übertragen werden. 36 Es 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 37 TK-Anlagen genutzt. 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 38 (SG) benötigt, dessen Daten z.B. mittels SIGTRAN-Protokollen , wie das bereits oben erwähnte Trans39 portprotokoll SCTP, an das MGC gegeben werden. Einen Überblick gibt folgendes Bild[3] : 35 http://de.wikipedia.org/wiki/MGCP 36 http://de.wikipedia.org/wiki/Megaco 37 vgl. Badach 2007, S. 287 ff. 38 SIGTRAN: IETF Working Group, die sich mit Signalisierung von und zu PSTN beschäftigt 39 http://www.syrus.ru/files/devices/mon/masterquest/75.gif 3 Protokolle und Standards im Überblick 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. Protokoll Beschreibung RFC/ITU DNS Domain Name System (Application Layer) DNS wird RFC 1034, hauptsächlich zur Umsetzung von Domain-Namen in 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 40 ENUM bezeichnet.[1] 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 System E.164 (DNS) um E.164-Nummern zu speichern und ist in der Lage, Dienste zu kennzeichnen, die unter einer E.164-Nummer 40 http://de.wikipedia.org/wiki/Domain_Name_System 3 Protokolle und Standards im Überblick 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 41 42 von deren Protokollen betrachtet werden.[2] [3] 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 "+441164960348" wird zu: 3.8.0.0.6.9.2.3.6.1.4.4.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 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:[email protected]!" . NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:[email protected]!" . NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:[email protected]!" . NAPTR 10 103 "u" "E2U+tel" "!^.*$!tel:+441164960348!" . Folgendes wird damit beschrieben: Die Domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. ermöglicht eine Kommunikation mittels SIP, H.323 für Sprache und SMTP für EMail. Die Kürzel "sip", "h323", "msg" und tel" haben hierbei keinen direkten Bezug zu den Protokollen oder zum URI-Schema. 41 http://tools.ietf.org/html/rfc3761 42 http://www.itu.int/rec/T-REC-E/en 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. 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): http://www.ietf.org IETF Tools, insbesondere RFC: http://tools.ietf.org International Telecommunication Union - Telecommunication Standardization Sector (ITU-T): http://www.itu.int/ITU-T European Telecommunication Standards Institute(ETSI): http://www.etsi.org Wikipedia, englische Version: http://en.wikipedia.org Wikipedia, deutsche Version: http://de.wikipedia.org Global IP Telecommunications, Inc.: http://www.xten.de Wireshark network protocol analyzer: http://www.wireshark.org Network Sorcery, RFC Sourcebook: http://www.networksorcery.com Syrus: http://www.syrus.ru/ 6 VoIP Diensteanbieter 6 VoIP Diensteanbieter Anbieter Hompage Anwendung Skype http://www.skype.com/intl/de/ http://www.skype.com/intl/de/download/features/ Gizmo http://www.gizmoproject.com/intl/de/ http://www.gizmoproject.com/intl/de/learn-more.html T-Online http://www.t-online.de http://service.t-online.de/c/12/71/61/14/12716114.html SparVoIP http://www.sparvoip.de/ http://www.sparvoip.de/de/instructions.html LowRateVoIP http://www.lowratevoip.com http://www.lowratevoip.com/en/instructions.html Google Talk http://www.google.com/talk/ http://www.google.com/talk/about.html Anbieter Peter zahlt Gelbe Seiten Marcophone Hompage http://www.peterzahlt.de/ Anmerkung Web-Initated Call Services: GoYellow http://maps.gelbeseiten.de/ Direktverbindung Click-and-Call http://marcophono.de/ Joke-Anwendung 22 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ß) 7 Anlagen 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 24 7 Anlagen marcophon Eingabeseite: 25
