Rheinisch-Westfälische Technische Hochschule Aachen

Lehrstuhl für Informatik IV

Prof. Dr. rer. nat. Otto Spaniol

H.323 und SIP

Proseminar: Internetprotokolle für die

Multimediakommunikation

Wintersemester 2002/2003

Lanlan Zhang Matrikel-Nr.: 236726

Xiaochun Xu Matrikel-Nr.: 236725

Betreuung: André Schüppen Stefan Diepolder Lehrstuhl für Informatik IV, RWTH Aachen

H.323 und SIP 2

Inhaltverzeichnis

Kapitel 1 Einleitung 3

Kapitel 2 Das H.323 Protokoll 4 2.1 Einleitung 4 2.2 H.323 Architektur 4 2.2.1 Bestandteile von H.323 4 2.2.2 H.323 Protokoll Stack 6 2.3 H.323 Kontrolle und Signalisierung 8 2.3.1 H.225: RAS-Signalisierung 8 2.3.2 H.225: Call-Signalisierung 11 2.3.3 H.245: Kontroll-Signalisierung 16

Kapitel 3 Das SIP Protokoll 223.1 Einleitung 22 3.2 IETF-Architektur 22 3.3 SIP-Komponenten 23

3.3.1 Adressen 23 3.3.2 Netzwerkkomponenten 24

3.4 SIP-Nachrichten 26 3.4.1 Überblick über die SIP-Nachrichten 26 3.4.2 SIP Anfragen 28 3.4.3 SIP Antworten 29 3.4.4 Nachrichtenkopf 31

3.5 Abläufe 35 3.5.1 Registration 36 3.5.2 Direkte Verbindung 37 3.5.3 Verbindung über Redirect-Server 38

Kapitel 4 SIP versus H.323 404.1 Interworking zwischen SIP und H.323 40 4.2 SIP vs H.323 41

Literatur 44

H.323 und SIP 3

Kapitel 1 Einleitung

Das Internet ist heutzutage für den Austausch von Informationen und Daten über die ganze Welt unverzichtbar. Der Austausch von Informationen und Daten über das Internet kann in zwei Arten unterteilt werden: echtzeitig, wie z. B. IP-Telefonie und nicht-echtzeitig, wie z. B. Email. Eine Echtzeitplattform stellt normalerweise andere Anforderungen an die Netzwerkumgebung als eine Nicht-Echtzeit-Plattform. Die entscheidende Anforderung einer Echtzeitplattform ist die Übertragung in Echtzeit. Im Vergleich dazu wird der Verlust von auszutauschenden Daten eher toleriert. Um die Echtzeitübertragung zu sichern, müssen außer TCP und UDP noch weitere Protokolle hinzukommen. In den Echtzeitplattformen für Multimediasitzungen werden viele Protokolle für verschiedene Zwecke u. a. (De-)Kodierung, Sitzungskontrolle, Datenübertragung, Qualitätskontrolle usw. verwendet. Für die Sitzungskontrolle stehen im Wesentlichen die H.323 Protokoll-Familie von der International Telecommunications Union -Telecommunication Sector (ITU-T) und das Session Initiation Protocol (SIP) von der Internet Engineering Task Force (IETF) zur Verfügung. In den ersten beiden Kapiteln werden diese beiden Alternativen beschrieben. Im letzten Kapitel werden noch ein Vergleich und ein Modell für die Zusammenarbeit zwischen den beiden gegeben.

H.323 und SIP 4

Kapitel 2 Das H.323 Protokoll 2.1 Einleitung H.323 beinhaltet eine Reihe von Empfehlungen und wurde von der ITU-T veröffentlicht. Dieser Standard legt fest, wie PCs untereinander kommunizieren, um Audio- und Videodatenströme innerhalb von Computernetzwerken - z. B. im Intranet oder Internet - zu übertragen. H.323 beschreibt die Struktur eines Videokonferenzsystems über paketbasierte Netzwerke und nimmt dabei auf verschiedene andere Standards (H.225, H.245) Bezug. Man kann somit bei H.323 von einer Sammlung von Standards sprechen. Die erste Version von H.323 wurde im Jahr 1996 unter dem Namen „Packet based Multimedia Communication Systems“ veröffentlicht und ermöglichte multimediale Kommunikation über lokale Netzwerke (LAN). Zwei Jahre später erfolgte mit der zweiten Version von H.323 eine Erweiterung auf alle IP-basierten Netzwerke. Dazu gehören Local Area Network (LAN), Metropolitan Area Network (MAN) und Wide Area Network (WAN). Die zweite Version von H.323 wird heute häufig für VoIP-Lösungen verwendet. Zusammen mit anderen Standards bildet H.323 eine Standard-Familie für Multimediakommunikation über verschiedene Netzwerke. So gibt es Spezifikationen für die Kommunikation über ISDN (H.320), ATM (H.321) und PSTN (H.324). Alle diese Systeme sind darauf ausgelegt, dass ihre Komponenten mit Endgeräten der anderen Konferenzsystemklassen kooperieren können. Der Standard spezifiziert sowohl Punkt-zu-Punkt-Verbindungen als auch Mehrpunkt-Verbindungen. 2.2. H.323 Architektur 2.2.1 Bestandteile von H.323 H.323 Terminal H.323 Terminal

IP-basiertes Netzwerk

H.323 MCU H.323 Terminal H.323 Gatekeeper H.323 Gateway

Narrowband ISDN

Breitband ISDN

GSTN

Abbildung 2-1: H.323 Bestandteile.

H.323 und SIP 5

H.323 spezifiziert vier logische Komponenten, Terminals, Gateways, Gatekeepers und Multipoint Control Units (MCUs). Terminals, Gateways und MCUs werden als Endpunkte bezeichnet. Das Hauptziel von H.323 ist, den Austausch des Medienstroms zwischen den H.323-Endpunkten zu ermöglichen. H.323-Terminal

Ein H.323-Terminal ist ein Endpunkt, der Echtzeitkommunikation mit anderen H.323- Endpunkten anbietet. Dieses Terminal muss mindestens einen Audio-Codec unterstützen und kann optional andere Audio-Codecs und/oder Video-Codecs unterstützen. H.323-Gateway

Ein H.323-Gateway ist ein Endpunkt, der einen Übersetzungsdienst zwischen H.323-Netzwerk und Netzwerken anderer Typen anbietet, wie z.B ISDN. Eine Seite des Gateways unterstützt H.323-Signalisierung und beendet die Paketübertragung nach den Anforderung von H.323. Die andere Seite des Gateways ist die Schnittstelle zu einem leitungsvermittelten (circuit-switched) Netzwerk und unterstützt dessen Übertragungseigenschaften und Signalisierungsprotokolle. Auf der H.323-Seite hat der Gateway die Eigenschaft eines H.323-Terminals. An der leitungsvermittelten Seite hat der Gateway die Eigenschaft eines Knotens des entsprechenden Netzes. Der Gateway bietet unterschiedliche Dienste an, die in der Empfehlung H.246 spezifiziert sind: - Übersetzung zwischen Übertragungsformaten (z.B. H.225 zu H.221) und zwischen Kommunikationsprozeduren (z.B. H.245 zu H.242). - Verbindungsaufbau und –abbau sowohl auf Netzwerk- als auch auf PSTN-Seite - Übersetzung zwischen unterschiedlichen Video-, Audio- und Datenformaten H.323-Gatekeeper

Ein Gatekeeper ist ein optionales Objekt im H.323-Netzwerk. Wenn vorhanden, steuert der Gatekeeper einige H.323-Terminale, Gateways und MCs (Multipoint Controllers). Steuerung heißt, dass der Gatekeeper den Netzwerkzugang von einem oder mehreren Endpunkten autorisiert und z.B. Calls von einem Endpunkt unter seine Kontrolle erlauben oder ablehnen kann. Die Menge von Terminals, Gateways und MCs, die ein Gatekeeper kontrolliert, wird als Zone bezeichnet. Zu beachten ist, dass ein Gatekeeper die Endpunkte in mehreren Subnetzwerken als eine gesamte Zone behandelt. MC, MP und MCU

Ein MC ist ein H.323-Endpunkt, der Multipoint-Konferenzen zwischen zwei oder mehreren Terminals und/oder Gateways verwaltet. Ein Multipoint Prozessor (MP) ist hingegen Teil einer MCU und empfängt Audio-, Video- und Datenströme von Endpunkten in zentralen Multipoint-Konferenzen und sendet diese nach erfolgter Verarbeitung zu den Endpunkten zurück. Eine MCU nimmt einen zentralen Stellenwert in der Mehrpunktkommunikation ein,

H.323 und SIP 6

da sie die Unterstützung für Multipoint-Konferenzen bietet. Sie besteht aus einem MC und kann (muss aber nicht) durch ein oder mehrere MPs ergänzt sein. 2.2.2 H.323 Protocol Stack Abbildung 2-2 zeigt den H.323 Protocol Stack. Man kann zuverlässige und unzuverlässige Transportprotokolle unterscheiden. In einem IP-Netzwerk sind dies entsprechend das TCP (Transport Control Protocol) und UDP (User Datagram Protocol). Aus dieser Abbildung ist der Austausch von Medien durch Benutzung von RTP über UDP zu erkennen. In der Abbildung finden wir noch zwei weitere Protokolle: H.225 und H.245. Diese beiden Protokolle definieren die Echtzeitnachrichten, die zwischen H.323 Endpunkten ausgetauscht werden. Dies sind allgemeine Protokolle, d.h. sie können in einer Reihe von Netzwerkarchitekturen benutzt werden. In H.323-Netzwerken werden H.225- und H.245-Protokolle in H.323 spezifiziert.

Audio/Video Application

Terminal /Application Control

Audio/Video Codecs

RTP

RTCP

H.225.0 RAS

Signaling

H.225.0 Call

Signaling

H.245 Control

Signaling

Unreliable Transport Reliable Transport

Network Layer(IP)

Data Link Layer

Physical Layer

Überblick über H.323-P

H.225 ist ein zweiteiligesTerminierung der KommSignalisierung dieses Typs andere Teil von H.225 ist Endpunkten und GatekeeVerwaltung der EndpunktRAS-Signalisierung zur Redie Signalisierung zum Zulzu den Netzwerkressourcen 1 Registration, Administra

Abbildung 2-2: H.323 Protocol Stack.

rotokolle Protokoll. Der eine Teil wird für die Initiierung und unikationen zwischen H.323-Endpunkten benutzt. Die heißt Call-Signalisierung oder Q.931-Signalisierung. Der

RAS1-Signalisierung. Diese Signalisierung wird zwischen pern benutzt und ermöglicht einem Gatekeeper die e in seiner Zone. Zum Beispiel benutzt ein Endpunkt gistrierung bei einem Gatekeeper, während ein Gatekeeper assen oder zur Ablehnung des Zugangs eines Endpunktes nutzt. tion und Status

H.323 und SIP 7

H.245 ist ein Kontrollprotokoll, das zwischen zwei oder mehreren Endpunkten benutzt wird. Der Hauptzweck von H.245 ist, die Medien-Ströme zwischen den Teilnehmern in einer H.323-Sitzung zu verwalten. H.245 arbeitet während der Einrichtung einer oder mehrerer logischer Kanälen zwischen Endpunkten. Die logischen Kanäle transportieren die Medienströme zwischen den Teilmehmern und besitzen eine Menge von Eigenschaften, wie z.B. den Typ von Medien, Bitrate, usw. Alle drei Signalisierungprotokolle (RAS, Q.931 und H.245) können zur Einrichtung, Verwaltung und Beendung eines Anrufs benutzt werden. Will z.B., ein Endpunkt einen Anruf an einen anderen Endpunkt richten, kann der Endpunkt die RAS-Signalisierung benutzen, um die Autorisation von einem Gatekeeper zu erhalten. Der Endpunkt kann dann Q.931-Signalisierung benutzen, um die Kommunikation mit dem anderen Endpunkt einzurichten und den Anruf zu beginnen. Zuletzt kann der Endpunkt H.245-Kontroll-Signalisierung benutzen, um Medien-Parameter mit anderem Endpunkt auszuhandeln und die Medientransformation zu beginnen. H.323-Nachrichten werden über Kanäle unterschiedlicher Typen abhängig von den Nachrichten (und in manchen Fällen, des Kontexts) gesendet. Zum Beispiel werden RAS-Nachrichten über die RAS-Kanäle, Call-Signalisierungs-Nachrichten über die Call-Signalisierungs-Kanäle, H.245-Kontroll-Nachrichten über die H.245-Kontroll-Kanäle und die Echtzeitmedienströme über einen oder mehrere logi-sche Kanäle gesendet. Es ist zu beachten, dass diese Kanäle nicht notwendig mit physikalischen Schnittstellen oder Hardware übereinstimmen. Ein Kanal in einer IP-Umgebung entspricht einer Referenz zu einer Socketadresse, nämlich der IP-Adresse mit Port-Nummer. H.323-Adressierung

Jedes Objekt im H.323-Netzwerk hat eine eindeutige Netzwerkadresse, die dieses Objekt identifiziert. In einer IP-Umgebung ist die Netzwerkadresse eine IP-Adresse. Falls Domain Name Service (DNS) vorhanden ist, kann die IP-Adresse in Form eines Uniform Resource Locators (URL) spezifiziert werden. Für jede Netzwerkadresse kann ein H.323-Objekt eine oder mehrere „Transport Service Access Point“ (TSAP)-Identifikationen haben. Allgemein ist eine TSAP- Identifikation eine Identifikation für einen besonderen logischen Kanal bei einem bestimmten Objekt. Auf der IP-Ebene ist die TSAP-Identifikation äquivalent zu einer Socketadresse, also einer IP-Adresse mit Port-Nummer. Im Allgemeinen sind die Port-Nummern, die für Signalisierung, Transaktion oder Medienaustausch benutzt werden, dynamisch zugeteilt. Die bedeutensten Ausnahmen sind hier folgende: - der Gatekeeper UDP Discovery Port mit dem Wert 1718, - der Gatekeeper UDP Registration und Status Port mit dem Wert 1719 und - der Call-Signalisierung TCP Port mit dem Wert 1720. Der erste Port wird verwendet, falls ein Endpunkt einen Gatekeeper, bei dem der Endpunkt registriert werden soll, deteminieren will. Der zweite Port wird für die RAS-Signalisierung zu einem Gatekeeper, z.B. eine Registrierung, verwendet. Der dritte Port wird beim Senden einer Call-Signalisierungs- Nachricht verwendet.

H.323 und SIP 8

Zusätzlich zur Netzwerkadresse und TSAP Identifikation ermöglicht H.323 auch Terminals und Gatekeepers, einen oder mehrere Aliases zu haben. Falls eine Sendung solcher Nachrichten mit reeler IP-Adresse adressiert werden muss, dann muss auch der Knoten über die Fähigkeit zur Übersetzung von Aliases in IP-Adressen verfügen. Diese Übersetzung ist normalerweise eine Funktionalität eines Gatekeepers und wird von der RAS-Signalisierung unterstützt. Codecs

In Abbildung 2-2 sehen wir eine Referenz zu Audio- und Videocodecs. Allerdings ist die Unterstützung von Video optional. Falls Video unterstützt wird, sollte ein Endpunkt Video nach H.261 Quarter Common Intermediate Format (QCIF) unterstützen. Optional können zusätzlich andere Modi von H.261 oder von H.263 intergriert werden. Unterstützung von Audio ist im Vergleich zu Video obligatorisch. Für die Kodierung und Dekodierung gibt es verschiedene ITU-Empfehlungen. In H.323 ist die Unterstützung von G.711 Codec erforderlich. Optional können auch die Codecs der Empfehlung G.722, G.728, G.729, MPEG 1 Audio und G.723.1 implementiert werden. 2.3 Kontrolle und Signalisierung 2.3.1 H.225, RAS-Signalisierung RAS-Signalisierung wird zwischen einem Gatekeeper und den Endpunkten, die der Gatekeeper kontrolliert, verwendet. Es ist zu beachten, dass ein Gatekeeper ein optionales Objekt in H.323 ist. Also ist RAS-Signalisierung dadurch auch optional. Falls ein Endpunkt die Services von einem Gatekeeper benutzen will, dann muss der Endpunkt RAS implementieren. Falls der Endpunkt keinen Service von einem Gatekeeper benutzen will, dann muss die Funktionalität, die normalerweise ein Gatekeeper besitzt, von dem Endpunkt selbst ausgeführt werden. RAS-Signalisierung ist in H.225 definiert und unterstützt folgende Funktionen: - Gatekeeper Discovery : Ermöglicht einem Endpunkt festzulegen, welcher

Gatekeeper die Möglichkeit hat, den Endpunkt zu kontrollieren. - Registration : Ermöglicht einem Endpunkt sich bei einem bestimmten Gatekeeper

zu registrieren und in die Zone dieses Gatekeepers einzutreten. - Unregistration : Ermöglicht einen Endpunkt, die Kontrolle von einem Gatekeeper

zu verlassen oder einen Gatekeeper, die existierende Registration eines Endpunkts zu stoppen und den Endpunkt aus der Zone zu entfernen.

- Admission : Verwendet von einem Endpunkt, um Zugang zu einem Netzwerk zur Teilnahme an einer Sitzung anzufordern. Eine Anfrage für den Zutritt spezifiziert die Bandbreite, die der Endpunkt benutzt. Der Gatekeeper kann daraufhin die Anfrage entsprechend der verfügbaren Bandbreite erlauben oder ablehnen.

- Bandwidth Change : Benutzt von einem Endpunkt, um den Gatekeeper um Zuteilung einer bestimmten Bandbreite für den Endpunkt zu bitten.

- Endpoint Location : Eine Funktion zur Übersetzung von einem Alias in eine Netzwerkadresse bei einem Gatekeeper. Ein Endpunkt ruft diese Funktion auf,

H.323 und SIP 9

falls er eine Verbindung zu einem bestimmen Endpunkt aufbauen will, der nur eine Alias-Identifikation hat. Der Gatekeeper teilt daraufhin die Netzwerkadresse mit, so dass der Endpunkt, der die Anfrage stellt, mit dem gewünschten Endpunkt in Kontakt treten kann.

- Disengage : wird von einem Endpunkt verwendet, um einen Gatekeeper zu informieren, dass er einen bestimmten Anruf trennen soll. Disengage kann auch von einem Gatekeeper zu einem Endpunkt gesendet werden, um einen Endpunkt zur Trennung von einem Anruf zu zwingen.

- Status : Verwendet zwischen einem Gatekeeper und Endpunkt, um den Gatekeeper über relevante Daten zu informieren, wie z.B. aktuelle Bandbreitee usw.

- Resource Availability : wird von einem Gateway versendet, um den Gatekeeper über seine aktuell verfügbare Kapazität zu informieren, wie z.B. die verfügbare Bandbreite. Ein Gateway kann diese Funktion auch benutzen, um einen Gatekeeper zu informieren, dass das Gateway schon seine Kapazität erreicht hat oder bereits darüber hinaus geht.

Die folgende Tabelle zeigt eine Liste von verschiedenen Nachrichten, die zur Unterstützung dieser Funktionen benutzt werden, und gibt eine kurze Beschreibung über das Ziel jeder Nachricht an. Tabelle : RAS Nachrichten Nachricht Funktion GatekeeperRequest(GRQ) Benutzt von einem Endpunkt zur Feststellung

von verfügbaren Gatekeepers. GatekeeperConfirm(GCF) Benutzt von einem Gatekeeper, um einem

Endpunkt mitzuteilen, dass er der Gatekeeper des Endpunkts ist oder sein wird.

GatekeeperReject(GRJ) Benutzt von einem Gatekeeper, um einem Endpunkt mitzuteilen, dass er kein Gatekeeper des Endpunkts ist oder sein wird.

RegistrationRequest (RRQ)

Benutzt von einem Endpunkt zur Registrierung bei einem Gatekeeper.

RegistrationConfirm (RCF)

Die positive Antwort von einem Gatekeeper an einen Endpunkt über seine erfolgreiche Registrierung bei dem Gatekeeper.

RegistrationReject(RRJ) Die negative Antwort zu einer RRQ UnregistrationRequest (URQ)

Benutzt von einem Gatekeeper oder einem Endpunkt zum Stoppen einer vorhandenen Registration.

UnregistrationConfirm (UCF)

Benutzt von einem Gatekeeper oder einem Endpunkt zur Bestätigung einer Anfrage der Deregistrierung.

UnregistrationReject(URJ) Die negative Antwort zu ein URQ AdmissionRequest(ARQ) Wird von einem Endpunkt an einen Gatekeeper

gesendet, um einen Anruf zu beantragen.

H.323 und SIP 10

AdmissionConfirm(ACF) Benutzt von einem Gatekeeper um einem Endpunkt die Erlaubnis zur Teilnahme in einem Anruf zu erteilen

AdmissionReject(ARJ) Benutzt von einem Gatekeeper, um einem Endpunkt die Erlaubnis zur Teilnahme in einem Anruf zu verweigern

BandwidthRequest(BRQ) Gesendet von einem Endpunkt oder einem Gatekeeper, um eine Veränderung der zugeteilten Bandbreite anzufordern

BandwidthConfirm(BCF) Die positive Antwort zu einer BRQ BandwidthReject(BRJ) Benutzt von einem Gatekeeper oder Endpunkt,

um die Anfrage der Veränderung der Bandbreite abzulehnen; benutzt von einem Endpunkt nur, falls die neue Bandbreite nicht unterstützt werden kann

InfoRequest(IRQ) Gesendet von einem Gatekeeper zu einem Endpunkt zur Abfrage der Zustandsinformation.

InfoRequestResponse (IRR)

Gesendet von einem Endpunkt zu einem Gatekeeper nach Anforderung oder automatisch zum Liefern der Zustandsinformation.

InfoRequestAck(INCK) Gesendet von einem Gatekeeper zur Bestätigung des Empfangs einer IRR

InfoRequestNak(INAK) Gesendet von einem Gatekeeper während des Empfangs einer IRR, falls Fehler auftritt, z.B. beim Empfang einer Anfrage von einem nicht registrierten Endpunkt.

DisengageRequest(DRQ) Gesendet von einem Endpunkt oder Gatekeeper zur Trennung eines Endpunkts von einem Anruf.

DisengageConfirm(DCF) Die positive Antwort zu einer DRQ DisengageReject(DRJ) Die negative Antwort zu einer DRQ, z.B einer

DRQ von einem nicht registrierten Endpunkt LocationRequest(LRQ) Gesendet zu einem Gatekeeper, um Übersetzung

eines Alias in einer Netzwerkadresse zu bitten LocationConfirm(LCF) Eine Antwort zu einer LRQ mit der

angeforderten Adresse LocationReject(LRJ) Eine Antwort zu einer LRQ, falls keine

Übersetzung erfolgreich durchgeführt worden ist. Non-Standard Message (NSM)

Vendor-Spezifikation

UnknowMessageResponse (XRS)

Eine Antwort zu einer nicht bekannten Nachricht.

RequestInProgress(RIP) Gesendet von einem Endpunkt oder Gatekeeper als eine temporäre Antwort, falls die Bearbeitung einer Anfrage eine lange Zeit in Anspruch nimmt.

H.323 und SIP 11

ResourceAvailableIndicate (RAI)

Gesendet von einem Gateway an einen Gatekeeper, um den Gatekeeper über die aktuelle Kapazität des Gateways zu informieren

ResourceAvailableConfirm (RAC)

Gesendet von einem Gatekeeper als eine Anerkennung eines RAI

Damit ein H.323-Endpunkt die Dienste eines Gatekeepers nutzen kann, muss dieser bei einem (nicht bei mehreren) registriert sein. Zur Registrierung braucht der Endpunkt zuerst einen geeigneten Gatekeeper, der durch die Gatekeeper-Suche (GatekeeperDiscovery) gefunden wird. Der Endpunkt sendet dazu eine GatekeeperRequest (GRQ)-Nachricht. Diese Nachricht kann zu vielen bekannten Adressen oder zu der Gatekeeper’s DiscoveryMulticastAdresse und Port 224.0.1.41:1718 gesendet werden. Ein oder mehrere Gatekeeper können mit einer GatekeeperConfirm (GCF)-Nachricht antworten. Das bedeutet, dass diese Gatekeeper den Endpunkt kontrollieren wollen. Im Fall einer Ablehnung sendet ein Gatekeeper die GatekeeperReject (GRJ)-Nachricht. Zur Registrierung sendet der Endpunkt einen RegistrationRequest (RRQ) an den zugehörigen Gatekeeper. Bei einer erfolgreichen Registrierung sendet der Gatekeeper eine RegistrationConfirm (RCF) zurück. Im Fall einer Ablehnung sendet er RegistrationReject (RRJ). Nach einer erfolgreichen Registrierung ist das Endsystem mit seiner zugehörigen IP-Adresse bei diesem Gatekeeper gespeichert. Ein Endpunkt oder auch der Gatekeeper kann eine Registrierung aufheben. Diese erfolgt durch Senden eines UnregistrationRequest (URQ). Normalerweise beantwortet ein Gatekeeper dies mit einer positiven Konfirmation durch Senden einer UnregistrationConfirm (UCF)-Nachricht. Der Gatekeepr kann auch eine Ablehnung mit einem UnregistrationReject (URJ) senden, wenn z.B. ein Endpunkt nicht bei diesem Gatekeeper registriert ist. Wenn ein Endpunkt an einem Anruf teilnehmen will, sendet er an den zugeordneten Gatekeeper eine AdmissionRequest (ARQ)-Nachricht. Ein wichtiger Parameter dieser Nachricht ist der Bandbreite-Parameter. Die erforderliche Bandbreite für Nutzverbindung (RTP-Verbindung) wird angefordert. Der Gatekeeper bestätigt die Anforderung mit AdmissionConfirm (ACF). Hierbei kann auch eine geringere Bandbreitee als die geforderte zugesichert werden. Ein Gatekeeper kann auch einen AdmissionRequest mit einem AdmissionReject (ARJ) ablehnen. 2.3.2 H.225: Call-Signalisierung Call-Signalisierung ist eine zwischen Endpunkten benutzte Signalisierung, um die Einrichtung und Trennung von Anrufen zu ermöglichen. Die H.225-Call-SignalisierungsNachrichten sind eine Teilmenge von den Q.931-Nachrichten nach der H.225.0-Empfehlung. Q.931 ist ein ISDN Signalisierungprotokoll der Schicht 3 und beinhaltet eine große Menge von Nachrichten, die zu sehr an ISDN-Netzwerken orientiert sind. In der H.225.0-Empfehlung sind nur die zur H.323-Architektur passenden Q.931-Nachrichten einfach wiedergegeben bzw. weiter modifiziert, damit die Nutzer

H.323 und SIP 12

von H.323 nicht in dem Labyrinth von Q.931 die Orientierung verlieren. Die folgende Tabelle zeigt eine Liste von verschiedener Call-Signaling-Nachrichten und gibt eine kurze Beschreibung über das Ziel jeder Nachricht an. Tabelle : Call Signalisierung Nachrichten Nachricht Funktion Kommentar Alerting Gesendet von einem angerufenen Endpunkt,

um der anrufende Partei mitzuteilen, dass der angerufene Benutzer alarmiert ist

Muss unterstützt wer-den

Call Proceeding

Eine optionale temporäre Antwort, die von einem angerufenen Endpunkt oder Gatekeeper vor der Sendung der Connect Nachricht gesendet wird

Soll gesendet werden, falls der angerufene Endpunkt einen Gate-keeper benutzt

Connect Ankündigung, dass der angerufene Benutzer den Anruf schon akzeptiert hat.

Muss unterstützt wer-den

Progress Eine optional von dem angerufenen Endpunkt gesendete Nachricht vor der Connect Nachricht

Kann von einem angerufenen Gateway benutzt werden bei PSTN Interworking

Setup Eine Initialiserungs-Nachricht zur Einrichtung eines Anrufs

Muss unterstützt wer-den

Setup Ack- nowledge

Eine optionale Antwort zu einer Setup Nachricht

Kann von einem Gateway bei PSTN Interworking weitergeleitert werden.

Release Complete

Benutzt, um einen Anruf zum Ende zu bringen

Die Q.931 Release Nachricht wird nicht verwendet

User Infor- Mation

Eine optionale Nachricht zur Sendung von zusätzlichen Einrichtungsinformationen eines Anrufs.

Kann in Overlap- Signalisierung benutzt werden

Notify Eine optionale Nachricht zur Angabe der Vorstellung eines Benutzers.

Kann von dem anrufenden oder angerufenen Endpunkt benutzt werden

Status Gesendet in einer Antwort zu einer Status Inquiry Anfrage oder zu einer nicht erkennbaren Nachricht.

Optionale Nachricht; kann in beiden Richtungen gesendet werden

Satus Inquiry

Eine Nachricht, um den Remote-Endpunkt über den aktuellen Status aus seiner Perspektive abzufragen.

Kann in Konjuktion mit RAS Status Prozedur gesendet werden

H.323 und SIP 13

Facility(Q.932)

Benutzt zur Umadressierung eines Anrufs oder zum Einschliessen eines fortgeschritten Services

Kann von jedem End-punkt zu jeder Zeit be-nutzt werden; ist nütz-lich zur Informations- Übertragung, falls keine andere Nachricht gesendet werden soll

Die Setup-Nachricht ist die erste gesendete Call-Signalisierung-Nachricht, die beim Verbindungsaufbau von einem Endpunkt zu anderen geht. Falls ein Endpunkt einen zugeordneten Gatekeeper hat, wird diese Nachricht gesendet, nachdem der Endpunkt eine ACF erhalten hat. Wenn der Zielendpunkt die Setup-Nachricht schon bekommen hat und die Verbindungsaufbau-Prozedur läuft, kann er eine CallProceeding-Nachricht senden. Falls ein Gatekeeper vorhanden ist, sendet der Zielpunkt ARQ und empfängt von dem zugehörigen Gatekeeper die positive Quittung (ACF). Nach dem Erhalt der positiver Quittung sendet der Zielendpunkt die Nachricht Alerting zum Initiator. Wenn die Verbindung durch den Benutzer angenommen wird, sendet der Endpunkt Connect zum Initiator. Danach steht der RTP-Kanal für dem Austausch von Nutzdaten zur Verfügung. Beendt wird die Verbindung durch eine ReleaseComplete-Nachricht. Call Scenarios: In Netzen ohne Gatekeeper werden H.225-Nachrichten direkt zwischen den beiden Endpunkten ausgetauscht.

T In Netzen mit GatekeeBestätigung mit ACF köwerden. In der ACF wirdas Ziel gesendet werdeDas folgende Diagramm

erminal

Release Complete

H.245 Session Release

Media Exchange

H.245 Session Establishment

Connect

Alerting

Call Proceeding

Setup

T

per wird zuerst ARQ zum Gatennen die Call-Signalisierungs-Nad dem Initiator mitgeteilt, ob die n oder über den Gatekeeper gele zeigt die erste Situation an.

erminal

keeper gesendet. Nach der chrichten zum Ziel gesendet H.225-Nachrichten direkt an itet (routed) werden müssen.

H.323 und SIP 14

Terminal

Alerting ACF

Connect

H.245 Establishment

DCF DCF

DRQ DRQ Release Complete

H.245 Release

Media Exchange

ARQ Call Proceeding

Setup ACF

ARQ

Terminal Gatekeeper Gatekeeper In dem zweiten Fall gibt es noch zwei Varianten. In dem Fall, dass zwei Endpunkte bei unterschiedlichen Gatekeepern registriert sind, kann ein Gatekeeper entscheiden, dass die Call-Signalisierungs-Nachrichten über ihn geleitet werden müssen.

Terminal

ARQ

ACF

Terminal Gatekeeper Gatekeeper

Call Proceeding

Setup

Call Proceeding

Setup

A

RQ

H.323 und SIP 15

AAlerting

Connect Alerting

Connect

H.245 Establishment

Media Exchange

H.245 Release

DRQ

DCF

Release Complete Release Complete

DRQ

D

Das folgende Diagramm zeigt eine einfache Verbindung Nachrichten werden über die beiden Gatekeeper geleitet. Terminal

Setup Call Proceeding

Setup

ARJ

Release Complete

Fa

Call Proceedi

Setup Call Proceeding

Setup

ACF

ARQ

Gatekeeper Gatekeeper

CF

CF

mit Gatekeeper.

ARQ

cility

ng

T

erminal

H.323 und SIP 16

C

ARJ

Connect Connect

Release CompleteRelease Complete Releas

H.245 Release

Media Exchange

H.245 Establishment

2.3.3 H.245 Control Signalisierung H.245 ist ein Protokoll zur Einrichtung und Kontrolle von Mzwei Endpunkten, also in einem Zweiparteienanruf. Das Protdas Einverständnis, das zu sendende und das zu empfangendeBandbreitenanforderung. In viel komplexeren MultimediaanrProtokoll um das Multiplexen mehrerer Medienströme und eFunktionalitäten, wie Lippen-Synchronisation zwischen AudioH.245 ist ein Kontrollprotokoll, das die Mediensitzunggewährleistet es keine Verantwortung für die Übertragung der aH.245 kann nicht nur für VoIP verwendet werden, sondern, isProtokoll, das für die Kontrolle von Mediensströmen benuAnwendungen entworfen worden ist. H.245 Nachrichtsgruppen

H.245 umfasst das Senden der Nachrichten von einem EndpH.245-Nachrichten unterscheiden vier Grundtypen: - Requests : Diese Nachrichten erfordert die Ausführung v

direkte Response-Nachricht vom Empfänger . - Responses : Diese Nachrichten dienen als Antwort auf Requ- Commands : Diese Nachrichten fordern beim Emfaenge

Aktionen ohne explizite Antwort an. - Indications : Sind Nachrichten, die nur zur Information d

werden, sie erfordern keine Bestätigung. Das Konzept von logischen Kanälen

H.245 behandelt Medienströme durch Benutzung von lologischer Kanal ist ein unidirektionaler Pfad zwischen Allgemein, in einer IP-Umgebung, kann ein logischer K

all Proceeding

A

Con

e Co

edieoko Meufenrmö unden ktut eitzt

unk

on

estr d

er G

gisczweana

RQ

nect

mplete

nströmen zwischen ll kümmert sich um dienformat und die kümmert sich das glicht verschiedene Video. verwaltet, jedoch

ellen Medien. n mehr allgemeines wird und für viele

t zum anderen. Die

Aktionen und eine

-Nachrichten ie Ausführung von

egenseite gesendet

hen Kanälen. Ein i Endpunkten. Im l einfach als eine

H.323 und SIP 17

IP-Adresse mit Port-Nummer, die einen besonderen Typ von Medien unterstützt, betrachtet werden. Jeder logische Kanal hat eine Nummer, die von dem sendenden Objekt spezifiert wird. Logische Kanäle sind unidirektionale Pfade von Absendern zu Empfängern. Das heißt, in einem Zweiparteiengespräch existieren zwei logische Kanäle. Diese Trennung ermöglicht, dass ein Terminal die Medien in einem Format sendet und in einem anderen Format empfängt. Zur Einrichtung eines Medienstromes von einem Endpunkt zu einem anderen, öffnet der Absender einen logischen Kanal. Ein Endpunkt schickt die Nummer des logischen Kanals und Informationen über die zu sendenden Medien, wie z.B. den RTP paylood Typ, in einer Nachricht zu einem Remote-Endpunkt. Diese Nachricht heißt OpenLogicalChannel. Falls der Remote-Endpunkt die Medien empfangen will, antwortet er mit einer positiven Bestätigung (Open Logical Channel Ack). Die H.245 Nachrichten werden über die H.245-Kontrollekanäle übertragen. H.245 Prozeduren

H.245 enthält viele Prozeduren. Bevor ein logischer Kanal geöffnet werden kann, muss der Absender die Fähigkeinen des Empfängers kennen. H.245 enthält eine Prozedur: Capabilities Exchange, die einige Nachrichten, die zwischen den Endpunkten zum Austausch der Informationen über die Fähigkeiten jeweiliges Endpunkts gesendet werden können, enthält. Die Fähigkeiten sind z.B. Sendung und/oder Empfang von Medien, Feststellung der unterstützten bzw. gleichzeitig unterstützten Medienformaten. In einem Konferenzanruf mit zwei oder mehreren Endpunkten und einem MC kann ein Problem bei der Identifizierung, wer die Konferenz kontrolliert, auftauchen. Unter Umständen könnten zwei Endpunkte gleichzeitig einen dringenden Bedarf zur Kommunikation mit dem anderen haben und jeder versucht eine Sitzung mit dem anderen einzurichten. Um dieses Problem zu lösen, hat H.245 eine Prozedur: Master-Slave-Determination. Weil ein Endpunkt Medien in einem bestimmten Format behandeln kann, kann er ein bestimmtes Format gegenüber anderen bevorzugen. Weil Capability Exchanges es einem Endpunkt ermöglichen, den anderen Endpunkten über seine handhabbare Formate von Medien zu informieren, ist das Ranking von Formaten nach Bevorzugung durch eine Request Mode Prozedur möglich. Master-Slave-Bestimmung. (Master-Slave-Determination) Diese Prozedur dient der Auflösung von Konflikten zwischen zwei Endpunkten, die beide die Funktion eines MCs für eine Konferenz übernehmen können oder die beide einen bidrektionalen Kanal öffnen möchten. Austausch der technischen Fähigkeiten. (Capabilities Exchange) Mit den entsprechenden H.245-Prozeduren werden Send- und Empfangsfähigkeiten zwischen den Endpunkten ausgetauscht.

H.323 und SIP 18

Establishing and Releasing Media Stream Eine oder mehrere logische Kanäle übertragen Medienströme zwischen Teilnehmern. Diese Kanäle müssen eingerichtet werden, bevor die Medien ausgetauscht werden können, und am Ende dieses Anrufs geschlossen werden. (siehe Diagramm auf nächster Seite) Fast-Connect Prozedur

Im unten stehenden Diagramm sehen wir, dass ein solcher Anrufaufbau sehr kompliziert ist. Die Fast-Connect Prozedur ermöglicht einen möglichst schnellen Aufbau eines Medienstromes. Die Setup-Nachricht kann ein Schnell-Start-Element in das User-to-User-Element hinzufügen. Das Schnell-Start-Element ist eine (oder mehrere) OpenLogicalChannel-Anfragennachricht, die alle Informationen enthält, die normalerweise in einer solchen Anfragennachricht enthalten sind. Falls der angerufene Endpunkt auch diese Prozedur unterstützt, kann er ein Schnell-Start-Element in einer der CallProceeding, AlertingProgress oder Connect Nachrichten zurückschicken. Aufbau unidrektionaler logischer Kanäle Aufbau bidrektionaler logischer Kanäle T

erminal

Media Exchange

Open Logical Channel Ack{

Forward Logical Channel Number

Logical Channel Ack Parameters{

Transport Address}}

Open Logical Channel{

Forward Logical Channel Number

Data Type

Forward Channel Parameters{

Session ID

RTP PayLoad Type, etc.}}

T

erminal T

Media Exchange

Open Logical Channel Confirm{

Forward Logical Channel Number

}

Open Logical Channel Ack{

Forward Logical Channel Number

Reverse Logical Channel Parameters{

Reverse Logical Channel Number

Transport Address

RTP Payload Type, etc.}}

Open Logical Channel{

Forward Logical Channel Number

Data Type

Forward Channel Parameters{

Session ID

RTP PayLoad Type, etc.}

Reverse Channel Parameters{

Media Type

RTP Payload Type,etc}}

erminal T

erminal

H.323 und SIP 19

Abbau logischer Kanäle und Beenden einer Sitzung

Das Schnell-Start-Element ist grundsätzlich eine andere Form der OpenLogicalChannel-Nachricht, ähnlich der Anfrage zur Öffnung eines bidirektionalen logischen Kanals. Die Benutzung des Schnell-Start-Mediarismus ist im folgenden Diagramm beschrieben.

Gatekeeper

Combining RAS, Q.931, and H.245 Signalisierung (slow start)

Terminal

Request Channel Close

Forward Logical Channel Number

Reason

Request Channel Close Ack

Forward Logical Channel Number

Close Logical Channel

Forward Logical Channel Number

Source

reason

Close Logical Channel Ack

Forward Logical Channel Number

End Session

End Session

ARQ

ACF

Terminal

Terminal

Setup

Call Proceeding

Terminal G

ARQ

atekeeper

H.323 und SIP 20

A

ReleaseDRQ

DCF

OLC (bidi

O

OLC C

OLC C

Media

CLC

C

End Ses

En

Terminal

Connect (faststart [logic

Media Exchange

Gatekeeper

ARQ

Setup (faststart [logica

The Fast-Connec

ACF

ACF

lerting

Connect Connect

rectional)

LC Ack

onfirm

onfirm

Exchange

LC Ack

sion

d Session

Complete

DRQ

T

Alerting

al channel info])

l channel info])

Call Proceeding

t procedure

erminal

ARQ

A

DCF

G

CF

atekeeper

Konfe

Es gibt dieH.323 deKonferenzPre-arrangeiner sepaist eine admehr Teiln

D

Termin

H.323 und SIP

renz Calls Situation, in denen es viele Teilnehmer in einer Multipunkt-Kfiniert die MC zur Verwaltung einer Mehrpunkt-Konfverbindung kann auf zwei Arten aufgebaut werden: Eineed- Konferenz aufzubauen. Das bedeutet, dass sich alle Teilraten MCU, die die Konferenz kontrolliert, verbinden. Die an-hoc-Konferenz. Das bedeutet, dass ein Zweiparteienanruf aehmer erweitert wird.

Release complete DRQ

CF

DRQ

al Terminal

Setup (CID=N)

Connect (CID=N)

Capability exchange

Master-slave determination

Logical Channel Establichment

Media exchange

Multipoint Conference Multipoint Conference

Media Exchange

Logical Channel Establish

Master-slave determinati

Capability exchange

Connect (CID=N

Setup (CID=N)Media exchange

21

o

onferenz gibt. erenz. Eine ist es, eine

nehmern mit dere Technik uf drei oder

DCF

Terminal

ment

n

)

H.323 und SIP 22

Kapitel 3 SIP Protokoll 3.1 Einleitung

Das Session Initiation Protokoll (SIP) nach RFC-2543 ist ein Signalisierungs-protokoll zum Aufbau, Verwalten und Abbau von Multimedia- sitzungen. Dazu gehören z.B. IP-Telefonie und Multimediakonferenzen usw. SIP ist das von der IETF bevorzugte Protokoll gegenüber H.323. SIP ist ebenfalls das Protokoll für die Mobilkommunikation der dritten Generation (3G) des Universal Mobile Telecommunications Systems (UMTS) in der zweiten Phase der Netzrealisierung. Im Vergleich zur H.323-Protokollfamilie ist SIP selbst die Bezeichnung für das Protokoll, obwohl mehrere Protokolle mit SIP kombiniert werden können. Dagegen ist H.323 eine Bezeichnung für den gesamten Stack mit RAS, H.225, H.245 bzw. den entsprechenden Codecs usw., wie in Kapitel 2 vorgestellt wird. Viele Hersteller steigen momentan von H.323 zu SIP um und testen ihre Produkte, um sicher zu stellen, dass sie die Spezifikationen korrekt implementiert und eigene Produkte eine gute Kompatibilität mit den anderen haben.

3.2 IETF-Architektur

SIP wurde von der Internet Engineering Task Force (IETF) als Teil einer umfassenden Multimedia-Daten- und Kontrollarchitektur entwickelt, die im Vergleich zu H.323-Protokoll-Familie der ITU-T ein Light Weight Session Model darstellt. SIP kann mit vielen anderen IETF Protokollen zusammenarbeiten und hängt dabei nicht von einem der folgenden ab. Sie dienen lediglich zur Unterstützung: - Session Announcement Protocol (SAP): Zur Anzeige von Multimedien-

sitzungen über Multicast nach RFC-2974. - Session Description Protocol (SDP): Zur Beschreibung von Multimedien-

sitzungen nach RFC-2327. - Resource Reservation Protocol (RSVP): Signalisierungsprotokoll zur

Ressourcenreservierung nach RFC-2205. - Real-Time Transport Protocol (RTP): Echtzeitprotokoll zum Transport von

isochronen Datenströmen und QoS-Rückmeldungen nach RFC-1889. - Real-Time Streaming Protocol (RTSP): Zur Kontrolle von Streaming Media

nach RFC-2326.

SIP ist für den Aufbau, die Kontrolle und die Terminierung einer Multimedien- sitzung zuständig. Es beschreibt, zusammen mit anderen Protokollen, die

H.323 und SIP 23

Eigenschaften und die Teilnehmer einer Sitzung. Prinzipiell kann ein beliebiges Transportprotokoll für den Transport von Medien in einer SIP-Sitzung benutzt werden, jedoch ist RTP das am meisten benutzte Protokoll. SIP-Nachrichten und die eigentlichen Sitzungsdaten werden zumeist durch das selbe physikalische Verbindungsmedium transportiert, jedoch sollte das SIP--Signalisierung separat behandelt werden. Abbildung 3-2 zeigt die logische Struktur von Signalisierung- und Sitzungsdaten. Diese Trennung ist wichtig, da die Signalisierung mithilfe eines oder mehrerer Proxy- oder Redirect-Server am Ziel ankommen kann, während die Medienströme durch einen viel direkteren Pfad das Ziel erreichen. Diese Strategie ist analog zur Trennung von Signalisierung- und Mediendaten in H.323.

T

Die StAnfragan dendiesemAnschlClient TranspProtok

3.3 SIP-K 3.3.1 Ad

Wie bAntwoAdresshaben Üblichabgelei

erminal T

RTP Medienstrom

Abbildung 3-1: Trennung von Signalisierung- und Mediendaten.

IP Netzwerk

SIP

ruktur von SIP ist eine Client-Server Struktur: d.h. der Ce an den Server. Der Server bearbeitet die Anfrage und schi Client zurück oder leitet die Anfrage an einem anderen S Fall spielt der Server in der Weiterleitung wieder die Rolleießend sendet er die von dem anderen Server kommende Anzurück. SIP stellt nur minimale Anforderungen an das dortprotokoll. SIP ist z.B. nicht von TCP als darunterliegenoll abhängig, obwohl diese Kombination häufig getroffen wi

omponenten

ressen

ei allen anderen Signalisierungsprotokollen werden rten immer an bestimmten Adressen gesendet. In SIP en als SIP-URL (Uniform Resource Locators) bezeichnet. die Form user@host, was den Emailadressen seh

erweise kann die SIP-Adresse eines Benutzers von seinetet werden. Während aber eine Emailadresse eine mailto

erminal

lient stellt eine ckt die Antwort erver weiter (in eines Clients). tworten an den arunterliegende dem Transport- rd.

Anfragen und werden solche Diese Adressen r ähnlich ist. r Emailadresse -URL wie z.B.

H.323 und SIP 24

mailto:xu@home.netist, lautet eine SIP-URL sip:xu@home.net. SIP vermittelt Multimediensitzungen, die natürlich insbesondere auch Sprache enthalten können. Da SIP mit einem traditionellen Circuit-Switched-Network zusammenarbeiten kann, ist der User-Teil durch eine Telefonnummer ersetzbar. (z.B. in einer SIP-URL sip:3344556789@home.net). In einem Netzwerk kann eine solche Adresse zum Routing von Medienströmen zu einem Gateway genutzt werden, das den Zugang zum traditionellen Telefonnetz bietet. In einer SIP-URL können darüber hinaus weitere Parameter hinzugefügt werden. Um z.B. anzudeuten, dass der Anruf an eine Telefonnummer geht, kann man den Term user=phone einfügen. In diesem Fall sieht die SIP-URL wie folgt aus: sip:3344556789@home.net;user=phone. Die SIP-URL bietet auch eine Identifikation des Benutzers an. Damit kann der Benutzer in einem Netzwerk eindeutig identifiziert werden, völlig unabhängig, auf wie vielen Terminals sich der Benutzer eingeloggt hat. Das wird auch als Telemobilität bezeichnet.

3.3.2 Netzwerkkomponenten

Wie vorher erwähnt, definiert SIP zwei Basisklassen von Netzwerkkomponenten: Client und Server. Alle VoIP-Anrufe, die SIP verwenden, sind von einem Client erzeugt und terminieren bei einem Server. Ein Client kann sich in einem Benutzergerät befinden, z.B. ein PC mit Kopfhörer und Mikrofon oder ein SIP-Phone. Ein Client kann aber auch ein Server in der selben Plattform sein. Ein typisches Beispiel ist der Proxyserver, der immer beide Rollen, Client und Server spielt. In SIP sind insgesamt vier Arten von Servern vorgesehen: Proxy-Server, Redirect-Server, User-Agent-Server und Registrator. SIP-Proxy-Server Ein Proxy-Server in SIP ist ähnlich zu einem Proxy-Server für den Webzugang aus einem LAN. Ein Client sendet Anfragen zu dem Proxy-Server. Der Proxy- Server verarbeitet diese Anfrage entweder selbst oder leitet diese Anfrage nach möglicher Übersetzung oder Umformulierung an einen anderen Server weiter. Auf der Seite des anderen Zielservers sieht diese, von dem Proxy-Server weiter- geleitete Anfrage so aus, wie eine vom Client kommende Anfrage. Abbildung 3-2 zeigt den Einsatz eines Proxy-Servers. Der Anrufer lädt Xu@i4.informatik.rwth-aachen.de zur Besprechung ein, während Xu tatsächlich zu Hause ist. Die Einladung wird vom Proxy-Server an Xu@home.net weitergeleitet. Voraussetzung ist, dass der Proxy-Server schon weiß, dass Xu zuhause statt im Büro ist.

H.323 und SIP 25

Redirect-Server Ein Redirect-Server ist ein Server, der SIP Anfragen akzeptiert, anschließend die Zieladresse in eine oder mehrere neuen Adressen umwandelt bzw. übersetzt und dann wieder an den Anfragenabsender zurückschickt. Danach kann der Client eine Anfrage an die neue Adresse schicken. Ein Redirect-Server initiiert keinesfalls selbst eine SIP Sitzung. Abbildung 3-3 skizziert ein Beispiel, um die Arbeitsweise eines Redirect-Servers zu verdeutlichen.

A

R

User-Age Unter dClient-Apist die GeSIP-Anfraz.B. eine ein SIP-Gdie SIP-zurückschFunktionavon SIP mwird als U

nrufer@i4

XAntwort

Abbildung 3-2:Einsatz des Proxy-Servers.

Antwort

Anfrage: Xu@home

Proxy-ServerAnfrage: Xu@i4

Anrufer@i4edirect-Server Anfrage: Xu@i4

Antwort

Anfrage:Contact: Xu@home

ACK

Abbildung 3-3:Einsatz des Redirect-Servers.

nt-Client, User-Agent-Server und User-Agent

en Begriff User-Agent-Client (UAC) bezeichplikation, die eine SIP-Anfrage initiiert. Ein User-Aggenseite von einem User-Agent-Client (UAC). Der Ugen und kontaktiert den Benutzer. Tatsächlich funktionSIP-fähiges Telefon, sowohl als UAS als auch als UACerät, kann eine SIP-Anfrage initiieren. Im Vergleich daAnfrage empfangen und, nach der Bearbeitungicken. Unter Umständen kann ein Gerät aulitäten verfügen, so dass eine peer-to-peer Kommunöglich ist. Eine Einheit mit beiden Funktionalitäten voser-Agent(UA) bezeichnet.

u@home

X

Xu@home

nenAie

z, cikn

u@home

en wir eine t-Server (UAS) S akzeptiert die rt ein SIP-Gerät, . Ein UAC, z.B. u wird ein UAS

eine Antwort h über beide ation mit Hilfe UAC und UAS

H.323 und SIP 26

Registrator Ein Registrator ist für die Bearbeitung von SIP REGISTER Anfragen zuständig. In SIP ist das Konzept der Benutzerregistrierung zugrunde gelegt, womit ein Benutzer dem Netzwerk seine Verfügbarkeit mitteilen kann. Eine solche Registrierung wird durch die REGISTER-Anfrage von einem Benutzer an einen Registrator ausgelöst. Der typische Einsatz von Registrator ist fast immer mit einem Proxy-Server oder Redirect-Server kombiniert. Obwohl eine praktische SIP-Implementation den UAC, UAS, den Registrator sowie einen Proxy-Server oder Redirect-Server enthalten wird, enthält ein Netzwerk üblicherweise aber nur UAC und einem Proxy- oder Redirect-Server. Location-Server Ein Location-Server bietet den sogenannten Location-Service an, der die Zieladressen von Benutzern angibt und damit eine Weiterleitung bzw. Umleitung eines Anrufs an die richtige Adresse ermöglicht. Eine praktische Implementation eines Location-Servers kann durch den Einsatz einer Datenbank, in der die Registrationsinfomationen von Benutzern gespeichert sind, über einen Redirect- Server oder Proxy-Server realisiert werden. Dadurch kann eine aktuell gültige Adresse eines Benutzers dynamisch mithilfe einer Abfrage bei der Datenbank ermittelt werden.

Location-Server

A

3.4 3.4

Proxy-Server nrufer

Proxy-Server

Abbildung 3-4 Arbeitsweise des Location-Servers bei SIP.

SIP-Nachrichten

.1 Überblick über die SIP Nachrichten

SIP ist ein text-basiertes Protokoll (benutzt ISO-10646-Zeichedeswegen eine ähnliche Aussicht wie das Hypertext Transfer ProtocoDieser Vorteil der Verwandtschaft erleichtert die Umwanderunimplementierten HTTP-Parser in SIP-Parser. Obwohl diese Eigdeutlichere und bessere Lesbarkeit und Verständnis mit sich bringt, v

Angerufene

nmenge) und l (HTTP) hat.

g der schon enschaft eine erbraucht SIP

H.323 und SIP 27

dadurch wiederum mehr Bandbreite. SIP-Nachrichten sind entweder Anfragen von einem Client an einen Server oder Antworten von einem Server an einen Client. Jede Nachricht, unabhängig ob Anfrage oder Antworte, beginnt mit einer Startzeile, gefolgt von optionalen Nachrichtenköpfen und dem optionalen Nachrichtenteil. Aufbau der SIP-Nachrichten

Startzeile:

Antwort: SIP-Version, SP, Status-Code, SP, Reason-Phrase CRLF

Anfrage: Methode (INVITE, ACK, OPTIONS, etc.),

Anfragen-URI, SP, SIP-Version CRLF

Nachrichtenkopf:

General: (Accept, Call-ID, Contact, Cseq, Date, Encryption, etc.)

Anfragen: (Authorization, Hide, In-Reply-To, Max-Forwards,etc.)

Anworten: (Proxy-Authenticate, Retry-After, Server, etc.)

Objekten: (Allow, Content-Disposition, Content-Encoding, etc.)

SP: Leerzeichen

CRLF: Carriage-Return Zeile Feed

Nachrichtenteil (z.B. SDP, SAP,

RTSP. usw. )

Leerzeile

Nachrichtenköpfe

Startzeile

Wird nur eine Anfrage- uaus: Startzeile = Reques

Die Anfragezeile spezifiAntwortzeile in einer Anwird der Typ des Fehlers Der Nachrichtenkopf biAntwort. Der Anfragendangegeben. Auf diese Arhinzugefügt werden. Zumeingesetzt, um den näfehlerhaften Sitzungsau„Subject“-Feld, in dem mEmpfänger darüber entsablehnt. Der Nachrichtenteil beSitzung inklusive einer Beispiel kann man im Na

Abbildung 3-5 Aufbau der SIP Nachrichten.

nd Statusnachricht definiert, sieht die Startzeile wie folgt

tzeile | Statuszeile.

ziert den Typ der zu sendenden Anfrage, während die twort den Erfolg oder Fehler angibt. Bei einem Fehler bzw. der Grund angegeben.

etet zusätzliche Informationen über die Anfrage oder e und der Angefragte sind ebenfalls im Nachrichtenkopf t und Weise können weitere Informationen in Nachrichten

Beispiel wird das „Retry-after“-Feld in der Nachricht chsten Zeitpunkt eines neuen Versuchs nach einem fbau zu bestimmen. Ein weiteres Beispiel ist das

an die Betreff des Anrufs beschreiben kann, damit der cheiden kann, ob er diesen Anruf entgegennimmt oder

schreibt normalerweise den Typ der einzurichtenden Beschreibung über die auszutauschenden Medien. Zum chrichtenteil der Gegenseite Anrufspartei mitteilen, dass

H.323 und SIP 28

ein Voice-Codecs G.711 benutzt wird. Es ist zu beachten, dass die Syntax bzw. Semantik für den Nachrichtenteil nicht in SIP selbst definiert wird, sondern, abhängig vom kombinierten Protokoll, sehr stark variiert. Eine sehr häufig benutzte Kombination ist das oben schon erwähnte Protokoll SDP. Da SIP ein textbasiertes Protokoll ist, kann die Informationen anderer Codierungen gut in SIP integriert werden, so wird oft eine ISDN User Part (ISUP) Nachricht im binären Format im SIP-Nachrichtenteil transportiert. Dadurch kann man den Nachrichtenteil noch bei Interworking mit einem Public-Switched Telephone Network (PSTN), das Signalisierung System 7 (SS7) benutzt, einsetzen. Dabei ist SIP nicht daran „interessiert“, was in dem Nachrichtenteil enthalten ist. Solche Funktionalität ist ähnlich einem Briefumschlag: SIP trägt die Nachrichten von einem Endpunkt zum anderen, ohne dass die Informationen gelesen werden.

3.4.1 SIP-Anfragen

Eine SIP-Anfrage fängt mit einer Requestzeile an, die einen Methodentoken, eine REQUEST-URI und eine Beschreibung der SIP-Version enthält. Der Methodentoken identifiziert eine zu sendende Anfrage. Die REQUEST-URI gibt die Adresse des Zielorts an, wohin die Nachricht gesendet werden soll. Die drei Komponenten sind durch jeweils ein Leerzeichen getrennt und die Requestzeile wird mit einem Zeilenvorschub beendet: Request-Zeile = Method SP Request-URI SP SIP-Version CRLF.

Es sind insgesamt sechs verschiedene Methoden im RFC 2543 (und deswegen sechs Arten von Anfragen) spezifiziert: INVITE, ACK, OPTIONS, BYE, CANCEL und REGISTER. Wie der Name schon sagt, initiiert die INVITE-Methode eine Sitzung bzw. einen Anruf. Für einen einfachen Anruf zwischen zwei Ansprechparteien wird INVITE mit einer Beschreibung über den Anruf sowie den Typ der Medien benutzt, um den Anruf einzurichten. INVITE ist vergleichbar zu der Initial Address Message (IAM) von ISUP. Der Einsatz von INVITE in einem Konferenzanruf ist ähnlich einem Zweiparteianruf. Nachdem ein Client eine Antwort zu INVITE erhalten hat, sendet der Client eine positive Bestätigung (ACK) des Empfangs der Antwort. Zum Beispiel sei die Antwort zu einer INVITE, dass der Angerufene gerade beschäftigt und deswegen ein sofortiges Gespräch nicht möglich ist, dann wird der Anrufende ein ACK senden. Ein anderes Beispiel ist, dass der Angerufene schon alarmiert wurde und der Anruf fortgesetzt wird, dann wird der Anrufende kein ACK senden, denn so Antwort ist keine terminierte Antwort (auf diesen Begriff wird später genauer eingegangen).

H.323 und SIP 29

Die BYE-Methode terminiert eine Sitzung und kann von beiden Parteien erzeugt werden. Die Methode wird beispielsweise benutzt, wenn eine Partei den Hörer auflegt. Die OPTIONS-Methode fragt einen Server über seine Fähigkeit ab. Diese Methode wird benutzt, um z.B. festzustellen, ob ein UAC einen bestimmten Medientyp unterstützt bzw. wie ein UAC nach Empfang einer INVITE antworten wird. Die CANCEL-Methode terminiert eine ausstehende Anfrage (a pending request). Zum Beispiel kann CANCEL von einem Client benutzt werden, um eine Sitzung zu terminieren, falls er schon ein INVITE gesendet, aber noch keine terminierte Antwort erhalten hat. Eine vorstellbare Situation ist, dass ein Benutzer A, nach der Initiierung einer parallelen Suche nach einem Benutzer B in mehreren Registrators (wenn dieser sich bereits angemeldet hat), mit dem Benutzer B in Kontakt kommt und dann mit CANCEL die INVITE-Anfragen zu den anderen Registrators abbricht, weil der Kontakt durch ein Endgerät bereits entstanden ist. Ein UAC benutzt die REGISTER-Methode, um sich bei einem Server anzumelden oder seine Adresse zu registrieren. Damit weiß der Registrator, wo der Benutzer sich befindet. Der UAC kann sich bei einem lokalen SIP-Server während der Einrichtung einer Sitzung, oder bei einem schon bekannten Registrator, wessen Adresse schon in dem UAC konfiguriert ist, oder mit Multicast bei allen SIP-Servern bei der Mulicastadresse 224.0.1.175 registrieren lassen. Es kann sein, dass ein UAC sich bei mehreren Registrators registriert hat oder ein UAC mehrmals bei einem Server angemeldet ist. Eine solche Situation tritt ein, wenn sich ein Benutzer zu einem Zeitpunkt auf mehreren Terminals eingeloggt hat, die über den selben Server verfügen. In diesem Fall werden bei einem ankommenden Anruf alle Endgeräte gleichzeitig signalisieren. Dies wird auch als Personal Mobility bezeichnet.

3.4.2 SIP-Antworten

Die Startzeile fängt mit einer Statuszeile an. Diese Zeile enthält einen dreistelligen Statuscode einer Antwort und einen entsprechenden Textausdruck. Die Software auf einem Client wird den Statuscode interpretieren und dann unter Umständen darauf reagieren, während der Textausdruck als ein Klartext für den Benutzer dient. Die Syntax dieser Zeile sieht z.B. wie folgt aus: Statuszeile = SIP version SP status code SP reason-phrase CRLF. Im RFC 2543 werden die Statuscodes zwischen 100 und 699 definiert, wobei die erste Stelle des Statuscodes die Klasse der Antwort bezeichnet. Alle Statuscodes zwischen 100 und 199 gehören also zu der selben Klasse. Diese verschiedenen Klassen sind:

H.323 und SIP 30

1XX Information; z.B. 181 deutet das Weiterleitern des Anrufs an. 2XX Erfolg; nur 200 ist definiert. Es bedeutet, dass die Anfrage schon

verstanden und behandelt worden ist. Falls die Anfrage ein INVITE ist, teilt die Antwort 200 dem Client mit, dass der Angerufene den Anruf entgegengenommen hat.

3XX Redirection; z.B. deutet 302 an, dass der Angerufene unter der in der Anfrage benutzten Adresse nicht erreichbar ist und eine neue Anfrage an die in der Antwort mitgesendete neue Adresse gestellt werden soll.

4XX Anfragefehler; z.B. deutet 401 an, dass der Client nicht berechtigt ist, eine Anfrage zu stellen.

5XX Serverfehler; z.B. deutet 505 an, dass der Server die in der Anfrage benutzte SIP-Version nicht unterstützt.

6XX Globale Fehler; z.B. deutet 604 an, dass der Angerufe überhaupt nicht existiert.

Tabelle 3-1: Antworten in SIP. Alle Antworten außer den Informationen (1XX), sind so genannte terminierte Antworten. Die terminierten Antworten sollen mit ACK-Nachricht bestätigt werden, sofern die originale Anfrage ein INVITE ist. Die 1XX-Antworten sind provisorisch, daher ist keine Bestätigung nach RFC 2543 erforderlich. Die folgende Tabelle gibt eine komplete Liste aller in RFC 2543 definierten Statuscodes.

Kategorie Statuscode Ausdruck der Grund Information 100 Trying 180 Ringing 181 Call is being forwarded 182 Queued Erfolg 200 OK Redirection 300 Multiple choices 301 Moved permanently 302 Moved temporarily 305 Use Proxy 380 Alternative service Anfragefehler 400 Bad request 401 Unauthorized 402 Payment required 403 Forbidden 404 Not found 405 Method not allowed 406 Not acceptable 407 Proxy Authentication required 408 Request timeout

H.323 und SIP 31

409 Conflict 410 Gone 411 Length required 413 Request entity too large 414 Request-URI too long 415 Unsupported media type 420 Bad extension 480 Temporarily not available 481 Call leg/transaction does not exist 482 Loop detected 483 Too many hops 484 Address incomplete 485 Ambiguous 486 Busy here Serverfehler 500 Server internal error 501 Not implemented 502 Bad gateway 503 Service unavailable 504 Gateway timeout 505 SIP version not supported Globale Fehler 600 Busy everywhere 603 DecZeile 604 Does not exist anywhere 606 Not acceptable

Tabelle 3-2: Antworten und ihre Bedeutung. 3.4.3 Nachrichtenkopf

Im RFC 2543 werden eine Reihe verschiedener Nachrichtenköpfe definiert. Diese Köpfe sind in einer Anfrage bzw. Antwort enthalten und stellen weitere Informationen über die Nachricht bzw. für eine passende Behandlung der Nachricht zur Verfügung. In dieser Hinsicht sind diese Header ähnlich zu den Nachrichtenparametern bzw. Informationenelementen in jedem typischen Signalisierungsprotokoll, wie ISUP, Q.931 usw.. In einer INVITE-Nachricht deutet z.B. das „To:“-Feld auf den Angerufenen und das „From:“-Feld auf den Anrufenden hin. Im Folgenden wird die Verwendung und die Bedeutung der häufig benutzten Header erklärt. Eine vollständige Beschreibung aller Header ist im RFC 2543 enthalten. Es gibt vier Hauptkategorien von Nachrichtenköpfen: Generalköpfe, Anfragen- köpfe, Antwortenköpfe und Objektenköpfe. Die folgende Tabelle zeigt die Nachrichtenköpfe dieser vier Kategorien. Abhängig von Anfrage oder Antwort sind bestimmte Nachrichtenköpfe obligatorisch, optional oder nicht verfügbar.

H.323 und SIP 32

Generalkopf Anfragenkopf Antwortenkopf Objektenkopf Accept Authorization Allow Content-EncodingAccept-Encoding Contact Proxy-Authenticate Content-Length Accept-Language Hide Retry-After Content-Type Call-ID Max-Forwards Server Contact Organization Unsupported CSeq Priority Warning Date Proxy-Authorization WWW-Authenticate Encryption Proxy-Require Expires Route From Require Record-Route Response-Key Timestamp Subject To User-Agent Via

Tabelle 3-3 Nachrichtenköpfe. Die folgende Tabelle gibt ein Mapping zwischen Anfragen und Nachrichtenköpfen an. Dabei steht „X“ für obligatorisch, „O“ für optional und „-“ für nicht verfügbar. Die Headers, die in der oberen Tabelle aber nicht in der folgenden Tabelle erscheinen, sind in Anfragen nicht verfügbar. Nachrichtenkopf ACK BYE CAN INV OPT REGAccept - O O O O O Accept-Encoding - O O O O O Accept-Language - O O O O O Authorization O O O O O O Call-ID X X X X X X Contact O - - O O O Content-Disposition O O - O O O Content-Encoding O O - O O O Content-Language O O - O O O Content-Length X X - X X X Content-Type O O - O O O CSeq X X X X X X Date O O O O O O Encryption O O O O O O Expires - - - O - O From X X X X X X Hide O O O O O O In-Reply-To - - - O - - Max-Forward O O O O O O MIME-Version O O O O O O Organization - - - O O O

H.323 und SIP 33

Priority - - - O - - Proxy-Authorization O O O O O O Proxy-Require O O O O O O Record-Route O O O O O O Require O O O O O O Retry-After - - - - - O Response-Key - O O O O O Route O O O O O O Subject - - - O - - Supported - O O O O O Timestamp O O O O O O To X X X X X X User-Agent O O O O O O Via X X X X X X

Tabelle 3-4: Einsatz von Nachrichtenköpfen in Anfragen. Die folgende Tabelle zeigt ein Mapping zwischen Nachrichtenköpfen und Antworten an. Es ist zu beachten, dass das Einschließen eines bestimmten Nachrichtenkopfs in einer Antwort vom Statuscode der Antwort und der entsprechenden Anfrage abhängt. Manche Nachrichtenköpfe können nur mit bestimmten Statuscode kombiniert werden, andere können mit allen Statuscode kombiniert werden. Zum Beispiel kann der „Allow“-Feld mit 200 und 405 benutzt werden. Jedoch kann in einer Antwort zu einer OPTIONS-Anfrage nur 200 eingesetzt werden . Nachrichtenkopf Statuscode AC

K BYE

CAN

INV OPT REG

Accept Alle außer415 - - - - O O Accept 415 - O O O O O Accept-Encoding 415 - O O O O O Accept-Language 415 - O O O O O Allow 200 - - - O O O Allow 405 X X X X X X Authorization Alle O O O O O O Call-ID Alle X X X X X X Contact 1XX - - - O O - Contact 2XX - - - O O O Contact 3XX,485 - O - O O O Content-Disposition Alle O O - O O O Content-Encoding Alle O O - O O O Content-Language Alle O O - O O O Content-Length Alle X X X X X X Content-Type Alle O O - O O O Cseq Alle X X X X X X

H.323 und SIP 34

Date Alle O O O O O O Encryption Alle O O O O O O Expires Alle - - - O - O From Alle X X X X X X MIME-Version Alle O O O O O O Organization Alle - - - O O O Proxy-Autheneicate 401,407 O O O O O O Record-Route 2XX,401,484 O O O O O O Require Alle O O O O O O Retry-After 404,413,480,

486,500,503, 600,603

O O O O O O

Server Alle O O O O O O Supported Alle - O O O O O Timestamp Alle O O O O O O To Alle X X X X X X Unsupported 420 O O O O O O User-Agent Alle O O O O O O Via Alle X X X X X X Warning Alle O O O O O O WWW-Authenticate 401 O O O O O O

Tabelle 3-5: Einsatz von Nachrichtenköpfen in Antworten Generalkopf Die Generalköpfe können sowohl in Anfragen als auch in Antworten benutzt werden. Diese Köpfe enthalten die erforderlichen Grundinformationen für die Behandlung der Anfragen bzw. Antworten. Zum Beispiel wird eine Sitzung mit Hilfe von dem „Call-ID:“-Feld identifiziert. Einer der am meisten benutzten General-Header ist das „Contact:“-Feld, welches eine URL für eine zukünftige Kommunikation in einer bestimmten Sitzung angibt. In einer SIP-INVITE Anfrage könnte das „Contact:“-Feld unterschiedlich von dem „From:“-Feld sein, damit der Initiator einer SIP-Sitzung kein Teilnehmer der SIP-Sitzung sein muss. Diese Felder können in einer Konferenzsitzung, in der der Administrator die Sitzung nur organisiert und verwaltet aber nicht teilnimmt, verwendet werden. In einem SIP Netzwerk mit Proxy-Server ist das „Contact:“-Feld sehr nützlich, da die Anfragen üblicherweise durch einen oder mehrere Proxy-Server an den Empfänger ankommen. Das Feld kann noch in einer 302 Antwort (vorübergehend unterwegs) zur Angabe der aktuellen URI des Angerufenen eingesetzt werden. Anfragenkopf Die Anfragenköpfe können nur, wie der Name sagt, nur in SIP-Anfragen benutzt

H.323 und SIP 35

werden. Zum Beispiel kann der Absender eine Beschreibung über das Thema der aktuellen Sitzung in dem „Subject:“-Feld hinzufügen. Um die Priorität (emergency, urgent, normal, oder non-urgent) einer Sitzung anzudeuten, steht das „Priority:“-Feld zur Verfügung. Weiter kann noch die Authentifizierung mit Hilfe des „Authorization:“-Feldes realisiert werden. Antwortenkopf Antwortenköpfe beinhalten die in der Statuszeile nicht verfassbaren weiteren Informationen über die Antwort. Zum Beispiel kann der Server mit dem „Unsupported:“-Feld auf die von ihm nicht unterstützten Features hinweisen. Das „Retry-After“-Feld teilt dem Absender, falls der Angerufene momentan unterwegs ist, den nächsten möglichen Zeitpunkt mit, zu dem der Angerufene wieder erreichbar ist. Objektenkopf Die Objektenköpfe dienen zur Angabe des Typs und Formats der Informationen in einem Nachrichtenteil, und ermöglichen dann eine passende Behandlung der Informationen in dem Nachrichtenteil. - Das „Content-Length“-Feld spezifiziert die Länge eines Nachrichtenteils in

Oktetten. - Das „Content-Type“-Feld gibt den Medientyp eines Nachrichtenteils an. Zum

Beispiel sieht das „Content-Type“-Feld wie folgt aus: Content-Type: application/sdp, sofern SDP in einer SIP Sitzung benutzt wird.

- Das „Content-Encoding“-Feld gibt die in einem Nachrichtenteil benutzten zusätzlichen Codierungen an, damit der Client eine entsprechende Decodierung durchführen kann.

- Das „Allow“-Feld ist unabhängig von der Sitzungsbeschreibung. Das Feld kann in einer Antwort zur Angabe der von dem Server unterstützten Fähigkeiten hinzugefügt werden. Ein Beispiel dafür ist das obligatorische Einschließen des „Allow“-Feldes in einer 405 Antwort (tatsächlich Methode nicht erlaubt) mit der Angabe, was der Server unterstützt,

- Das „Expire“-Feld gibt die Gültigkeitsdauer des Inhalts in einer Nachricht. Er kann z.B. bei einer Anmeldung bei einem Registrator zur Bestimmung der Zeit der Aktivität verwendet werden.

3.5 Abläufe Bisher wurde die Theorie über das SIP erläutert. In diesem Abschnitt werden wir einige typische Sitzungen betrachten.

H.323 und SIP 36

3.5.1 Registration (Abbildung 3-6) In der unteren Abbildung hat sich Xu auf prozac@i4 eingeloggt. Das „Via:“-Feld enthält die Adresse des Initiators. In dem „Via:“-Feld wird noch das Transport- protokoll eingestellt, hier UDP. In dem „From:“-Feld wird der Initiator der Anfrage genannt, hier Xu@i4. In dem „To:“-Feld ist die Adresse des zu registrierenden Benutzers enthalten, d.h. das „From:“- Feld und „To:“-Feld enthalten die selbe Adresse. Es ist zu beachten, dass die Adresse des Registrators nicht in dem „To:“- Feld sondern in der ersten Zeile enthalten ist. Der Initiator kann noch die Idenfikation der Anfrage in dem „Call-ID:“- Feld bestimmen. In einer REGISTER-Anfrage ist kein

REGISTER sip:Registrator.i4 SIP/2.0Via: SIP/2.0/UDP prozac.i4 From: sip:Xu@i4 To: sip:Xu@i4 Call-ID: 123456@prozac.i4 CSeq: 1 REGISTER Contact: sip:Xu@prozac.i4 Expires: 7200 Content-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP prozac.i4 From: sip:Xu@i4 To: sip:Xu@i4 Call-ID: 123456@prozac.i4 CSeq: 1 REGISTER Contact: sip:Xu@prozac.i4 Expires:3600 Content-Length: 0

Xu@i4 Registrator Nachrichtenteil enthalten, da dkeine Beschreibung darüber entgesetzt. Mit einer Antwort 200 (In dieser Antwort sind zwei Köin der Anfrage. Das „CSeq:“- Fnamen in der Anfrage, hier REGAntwort ist immer die selbe wenthält die registrierte Adresse XXu@i4 an, dass diese Registrativom Registrator so geändert, dgültig ist. Die Obergrenze deAnwendungen sein sollte.

Abbildung 3-6 Anmeldung.

iese Nachricht keine Sitzung initiihält. Das „Content-Length:“- Feld OK) wird die REGISTER Anfrage ppfe, das„Via:“-Feld und „CSeq:“-Feeld besteht aus einer Integer-Zahl un

ISTER. Die Integer-Zahl in dem „ie in der Anfrage, hier die 1. Dau@prozac.i4. Mit Hilfe des „Expi

on für 2 Stunden gültig sein soll. Dass die Registration für Xu@prozr Gültigkeit ist ca. 136 Jahre, w

ert und deswegen ist deswegen auf 0 ositiv beantwortet. ld die selben, wie d dem Methoden- CSeq:“-Feld einer s „Contact:“-Feld

res:“-Feldes deutet ies wird allerdings ac.i4 für 1 Stunde as genug für alle

H.323 und SIP 37

3.5.2 Direkte Verbindung Die folgende Abbildung zeigt einen Anruf zwischen Xu@i4 und Diepolder@i4 an. Die Bedeutung der „Via:“-, „From:“-, „To:“-, „Call-ID:“-, „CSeq:“-Felder sind ähnlich zu dem obigen Beispiel. Die erste Zeile fängt mit INVITE und der Zieladresse an, die in diesem Beispiel mit der Adresse in dem „To:“-Feld identisch ist(in Sitzungen durch Proxy-Server sind diese zwei Felder verschieden). Der Inhalt dieses Anrufs, hier Meeting, wird in dem „Subject:“-Feld beschrieben. Die erste Antwort von Diepolder@i4 zu der INVITE Anfrage ist eine 180 Antwort, die andeutet, dass Diepolder@i4 alarmiert wird. Nachdem eine 200 Antwort zu Xu@i4 von Diepolder@i4 angekommen ist, sendet Xu@i4 anschließend eine ACK Bestätigung. Danach startet eine Unterhaltung. Nach der Unterhaltung wird beispielsweise Xu@i4 den Anruf beenden. Dann wird eine BYE Anfrage an Diepolder@i4 geschickt. Nach dem Emfang der Anfrage wird Diepolder@i4 sofort den Transport aller Mediendaten an Xu@i4 abbrechen und anschließend eine 200 Antwort abschicken. Hier ist zu beachten, dass die Integer-Zahl in dem „CSeq:“-Feld dieses mal um 1 erhöht, nämlich auf 2 gesetzt, wird. Auf diese Weise wird ein einfacher Anruf, ohne die Nutzung von Proxy-Server, Redirect-Server und anderen Services, aufgebaut, durchgeführt und beendet (vgl. Abbildung 3-7).

X

INVITE sip:Diepolder@i4 SIP/2.0 Via: SIP/2.0/UDP prozac.i4 From: Xu<sip:Xu@i4> To: Diepolder<sip:Diepolder@i4> Call-ID: 123456@prozac.i4 CSeq: 1 INVITE Subject: Vacation Content-Length: xxxxxx Content-Type: application/SDP (Nachrichtenteil)

SIP/2.0 180 Ringing Via: SIP/2.0/UDP prozac.i4 From: Xu<sip:Xu@i4> To: Diepolder<sip:Diepolder@i4> Call-ID: 123456@prozac.i4 CSeq: 1 INVITE Content-Length: 0

SIP/2.0 200 OK Via: SIP/2.0/UDP prozac.i4 From: Xu<sip:Xu@i4> To: Diepolder<sip:Diepolder@i4> Call-ID: 123456@prozac.i4 CSeq: 1 INVITE Subject: Vacation Content-Length: xxxxxxx Content-Type: application/SDP (Nachrichtenteil)

Du@i4

iepolder@i4

H.323 und SIP 38

ACK sip:Diepolder@i4 SIP/2.0 Via: SIP/2.0/UDP prozac.i4 From: Xu<sip:Xu@i4> To: Diepolder<sip:Diepolder@i4> Call-ID: 123456@prozac.i4 CSeq: 1 ACK Content-Length: 0

Conversation

BYE sip:Diepolder@i4 SIP/2.0 Via: SIP/2.0/UDP prozac.i4 From: Xu<sip:Xu@i4> To: Diepolder<sip:Diepolder@i4> Call-ID: 123456@prozac.i4 CSeq: 2 BYE Content-Length: 0

SIP/2.0 200 OK Via: SIP/2.0/UDP prozac.i4 From: Xu<sip:Xu@i4> To: Diepolder<sip:Diepolder@i4> Call-ID: 123456@prozac.i4 CSeq: 1 BYE Content-Length: xxxxxxx

3.5.3 Verbindung über R In der Abbildung 3-9 wird Redirect-Servers skizziert. der Abbildung 3-8, deshalDie INVITE-Anfrage von gesendet. RedirServer.i4 sdem Empfang der INVITEdie aktuelle Adresse vomwohin Xu@i4 nochmals mEmpfang dieser 302 AntwoBestätigung senden. DaDiepolder@home zu schickCall-ID erhalten, die CSeq

Abbildung 3-7 Zweiparteienanruf.

edirect-Server

ein Anruf von Xu@i4 an Diepolder@home mit Hilfe eines Ab der 4. Anfrage (INVITE) ist der weitere Verlauf wie in b werden hier nur die ersten drei Nachrichten betrachtet. Xu@i4 wird zuerst an den Redirect-Server RedirServer.i4 chickt eine 302 Antwort mit einem „Contact:“-Feld nach -Anfrage an Xu@i4 zurück. In dem „Contact:“-Feld wird Herrn Diepolder, nämlich Diepolder@home angedeutet, it einem INVITE eine Einladung versenden soll. Nach dem rt wird Xu@i4 eine ACK-Nachricht an RedirServer.i4 zur nach versucht Xu@i4 erneuert ein INVITE an en. Nach dem Empfang des neuen INVITE bleibt zwar die wird aber um eins erhöht.

H.323 und SIP 39

X Diepolder@homeRedirServer.i4

u@i4

INVITE sip:Diepolder@i4 SIP/2.0Via: SIP/2.0/UDP prozac.i4 From: Xu<sip:Xu@i4> To: Diepolder<sip:Diepolder@i4> Call-ID: 123456@prozac.i4 CSeq: 1 INVITE

INVITVia: SIFrom: XTo: DieCall-IDCSeq: 2

ACK sVia: SIFrom: XTo: DieCall-IDCSeq: 1

SIP/2.0 302 Moved TemporarilyVia: SIP/2.0/UDP prozac.i4 From: Xu<sip:Xu@i4> To: Diepolder<sip:Diepolder@i4>Call-ID: 123456@prozac.i4 CSeq: 1 INVITE Contact: Diepolder@home

. . . . .

Abbildung 3-8 Zweiparteien

E sip:Diepolder@home SIP/2.0P/2.0/UDP prozac.i4

u<sip:Xu@i4> polder<sip:Diepolder@i4> : 123456@prozac.i4 INVITE

ip:Diepolder@i4 SIP/2.0P/2.0/UDP prozac.i4

u<sip:Xu@i4> polder<sip:Diepolder@i4> : 123456@prozac.i4 ACK

.

anruf mit Redirect-Server

H.323 und SIP 40

Kapitel 4 SIP versus H.323 In diesem Kapitel wird ein Anwendungsbeispiel für die Zusammenarbeit von H.323 und SIP vorgestellt. Abschließend werden die beiden Protokollen verglichen. 4.1 Interworking zwischen SIP und H.323 Die beiden Protokolle SIP und H.323 kümmern sich um die Initiation, Kontrolle und die Terminierung von Multimediensitzungen. Da jedes Protokoll einer eigene Architektur zugrunde liegt und nur die in den definierten Nachrichten und Methoden bearbeiten kann, ist ein sogenanntes Interworking-Gateway nötig, das die beiden Protokolle implementiert, um den Informationaustausch zwischen den Netzwerk- objekten in den beiden Netzen, durchführen zu können. Unter Umständen spielt das Interworking- Gateway je nach den zu realisierenden Funktionalitäten gleichzeitig

1. an der H.322 Seite die Rolle eines H.323-Endpunkts und an der SIP-Seite die Rolle eines UAC oder ein UAS, oder

2. an der H.323 Seite die Rolle eines Gatekeepers und an der SIP-Seite die Rolle eines Registrators und/oder ein Proxy-Servers.

Eine weitere Funktionalität zur Übersetzung von H.323 Nachrichten in SIP Nachrichten und umgekehrt ist offensichtlich auch unverzichtbar. Eine Skizze eines einfachen Inter-Netzwerks sieht wie folgt aus:

Interworking-Gateway H.323 Terminal S

DaGrubeasehdazzusz.BSigdiewuFas

H.323 NachrichtenSIP Nachrichten

IP UAC

Abbildung 4-1 Interworking zwischen SIP und H.323

das H.323 aus mehreren Protokollen besteht und die Nachrichtenppen Schritt für Schritt (z.B. zuerst RAS, dann H.255 und H.245)rbeitet werden müssen, spielt das Round Trip Time (RTT) in H.323-r große Rolle, sofern die Fast-Connect Prozedur nicht benutzt wirdu ist SIP ein einheitliches und text-basiertes Protokoll und dadurätzlichen Informationen einfach durch Integration von anderen Pr. die Beschreibung über die Medien in SDP, gleichzeinalisierungnachrichten an den Zielort gesendet werden. Da die Unt Umwandlung von Slow-Connect in Fast-Connect schon in dem Krden, betrachten wir hier nur das Interworkingmodell, t-Connect-Prozedur an der H.323 Seite benutzt wird.

verschiedener gesendet bzw. Sitzungen eine . Im Vergleich ch können die otokollen, wie tig mit den erschiede bzw. apitel 2 erklärt in dem die

H.323 und SIP 41

Ein Anruf von SIP an H.323 wird wie folgt aussehen. (von H.323 an SIP analog)

S

4. DfübeMMwNwwzw - Dm

IGW HIP UAC

Two-way voice Two-way voice

ACK

m=audio 2000 RTP/AVP 0

INVITE To: Terminal@H323.net c=IN IP4 123.45.6.7 m=audio 8000RTP/AVP 0

180 (Ringing)

Connect faststart [logical chan info =G711 TX, G711 RX 123.67.8.9:2000

Setup faststart [logical chan info =G711 TX, G711 RX 123.45.6.7:8000

Abbildung 4-2 Anruf von SIP an H.323

2 SIP vs H.323

as Signalisierungsprotokoll SIP stellt im Vergleich zu H.323 eine sr den Aufbau, die Kontrolle, und die Terminierung von Mediensiden Protokolle sind ideal für die Entwicklung einer Lultimedienkommunikation. Es gibt inzwischen in ultimedienkommunikation zahlreiche Anwendungen, die in H.3orden sind. Zum Beispiel die in der Windows-Welt sehr bekaetmeeting. SIP ist im Vergleich zu H.323 noch ein „Kinder“ (seiieso ist der Erwachsene momentan weniger beliebt als das Kind, irklich besser? Um diese Fragen zu beantworten, brauchen wirischen H.323 und SIP.

Architektur as H.323 ist kein wirkliches „echtes“ Protokoll sodern eine Defonolithische Zusammenfassung von mehreren vorhandenen echten

.323 Terminal

Alerting

200 (OK) To: Terminal@H323.net c=IN IP4 123.67.8.9

tarke Alternative itzungen dar. Die ösung für die dem Bereich

23 implementiert nnte Applikation t März 99). Aber und ist das Kind einen Vergleich

inition bzw. eine Protokollen u.a.

H.323 und SIP 42

H.225, H.245 etc. Es beschreibt die Regeln für die Zusammenarbeit dieser Protokolle. Die Architektur von H.323 ist vertikal. Die drei Signalisierungsgruppen gewährleisten verschiedene Aufgaben in einer Sitzung, jede Änderung der Funktionalität in einer Signalisierungsgruppe hat unmittelbare Wirkungen auf die anderen Signalisierungs- gruppen, somit wird die Erweiterung von Features einer Anwendung immer aufwendiger. Falls irgendein Fehler in einer Signalisierungsgruppe existiert, besteht sogar die Gefahr, dass die gesamte Anwendung nicht benutzbar wird. Im Vergleich zu H.323 ist das SIP ein für die Multimedienkommunikation speziell entwickeltes echtes Protokoll. SIP hat eine modulare Architektur, womit die Erweiterbarkeit deutlich erhöht worden ist. Zum Beispiel kann die Information über die zu übertragenden Medien in SDP geschrieben und dann einfach in SIP in einen Nachrichtenteil integriert werden, während in H.323 eine solche Beschreibung in einer separaten H.245 Nachricht verfasst werden muss. - Unterstützung an Codecs Im H.323 werden nur die Audio- und Video-Codecs nach ITU-T verwendet. Diese Beschränkung gibt es bei SIP aber nicht. Da in SIP die Informationen über das Codecs in SDP geschrieben werden können und damit keine dem Medienformat entsprechende Änderung in den SIP-Nachrichten gemacht werden muss, besteht nur noch das Problem, ob die beide Gesprächsparteien über eine Applikation zur Bearbeitung der Medien verfügen. Deswegen sind mit SIP alle Codecs benutzbar. - Transport SIP kann sowohl mit TCP als auch mit UDP arbeiten. Zum einen, die Verwendung von UDP führt eine geringer Belastung an das System als die Verwendung von TCP; zum anderen ist UDP besser geeignet für den Transport von Echtzeit-Daten als TCP. Da TCP sicherstellt, dass die Pakete komplet und in der richtigen Reihenfolge an das Ziel kommen, wird durch Paketverluste eine große Zeitverzögerung verursacht, was für Echtzeit-Kommunikation unerwünscht ist. UDP gewährleistet im Vergleich zu TCP keinerlei Verantwortung für erneute Senden der verlorenen Pakete, als Resultat ist nur eine etwas Verschlechterung der Qualität festzustellen, die man aber ertragen kann. Im H.323 muss ein Gatekeeper, das für das Routing von Gesprächen zuständig ist, für die Dauer des Gesprächs die Datenströme verarbeiten und bei mehreren Teilnehmern eine Menge TCP-Verbindungen halten. Im SIP gibt es jedoch keine Netzwerkkomponente, die unbedingt mit TCP arbeiten muss. - Konferenzmodell Mit SIP kann jeder Benutzer Anfragen an Multicast-Adressen verschicken, ohne bestimmten Netzwerkkomponenten zu brauchen. Im Vergleich dazu ist im H.323 eine MCU oder eine MC sowie MP unverzichtbar, um eine Mehrparteienkonferenz zu halten. Das Konferenzmodell ist deswegen in SIP verteilt und in H.323 zentralisiert. Obwohl mit Hilfe von MCU eine dezentralisierte Konferenz auch stattfinden kann, wird aber diese „dezentralisierte“ Modell zerstört, falls die MCU die Konferenz verlässt.

H.323 und SIP 43

Die folgende Tabelle zeigt die wesentlichen Unterschiede zwischen H.323 und SIP an: SIP H.323

Architektur Modular monolithisch (vertikal)

Transportprotokoll UDP oder TCP TCP (UDP ist optional)

Modell Internet/WWW Telefonnetz (ISDN)

Codierung ASCII (textbasiert) binär, Q.931 (ASN.1)

verwandte Protokolle http Q.931, Q.Sig

Komplexität Gering hoch

erweiterbar Leicht schwer

Codec-Unterstützung alle IANA-Codecs nur Codecs nach ITU-T

Unabhängig vom Transportprotokoll

klein Klein

Firewall-Support Ja nein

Mehrpunktsignalisierung Ja nein

Konferenzmodell Verteilt Zentralisiert

Tabelle 4-1: Vergleich zwischen H.323 und SIP. Da sich der H.323-Ansatz sehr stark am klassischen Telefonnetz orientiert, während das SIP eine direkte Schnittstelle zum WWW besitzt, wird eine große Anzahl übergreifender Dienste per WWW nur für SIP zugänglich sein. Darüber hinaus kann SIP durch Interworking zwischen Internet und Telefonnetzen wiederum in die Telefon-Welt hinausgehen. Das ist auch der Grund, weshalb SIP das bevorzugte Protokoll für die Steuerung von UMTS-Endgeräten geworden ist.

H.323 und SIP 44

Literatur: Daniel Collins: Carrier Grade Voice over IP; McGraw-Hill, 2001. Kai-Oliver Detken: Echtzeitplattformen für das Internet; Addison-Wesley,2002. Jörg Endrullis, Patrick Scheibe und Robert Höhndorf: Voice Over IP; http://leechuck.de/voip/. Andreas Büsching und Dirk Meyer: H.323-Gatekeeper und SIP-Proxy; http://www.informatik.uni-bremen.de/grp/unitel/referat/h323sip/. Gerd Siegmund: Next Gerneration Networks; Hüthig Verlag, 2002. RFC 2326, RFC 2327, RFC 2205, RFC 1889, RFC 2974, RFC 2543; http://www.ietf.org/rfc.html.