Warum IMS? Was leistet die neue Netztechnik des IP Multimedia Subsystem?

Jens Andresen, Customer Solution Manager, Ericsson GmbH, Düsseldorf Kein anderer Begriff aus der Standardisierung ist derzeit in der Telekommunikation (und mittlerweile nicht nur dort) so oft zu hören wie IMS. Das „All-IP Multimedia Subsystem“ hat sich in den letzten Jahren zu einem der wichtigsten Themengebiete der ITK Industrie entwickelt, denn IMS bedient auf fundamentale Weise eine Reihe von Megatrends der Kommunikationsindustrie, wie All-IP, Fixed Mobile Convergence, Konvergenz von Telekommunikation und IP-Welt. Und es gibt kaum einen Analysten, der die Einführung von IMS nicht als quasi fest vorgeschrieben für einen Netzbetreiber sieht. Allerdings wird sich jeder interessierte Beobachter der Telekommunikation, der sich an der Diskussion um die Vorteile dieses NGN-Standards beteiligen möchte, einer neuen Welt gegenübersehen. So konvergent wie der IMS-Standard selbst sind auch die Quellen, die zu seinem Verständnis zu Rate gezogen werden müssen. Dieser Artikel versucht daher, eine IMS-Einführung für den technisch versierten Leser zu geben sowie die Flexibilität von IMS anhand von einigen technischen Grundlagen mit Fokus auf die grundlegenden Verkehrsmechanismen von IMS zu erläutern. Weitere wichtige Aspekte von IMS wie Vergebührung, Sicherheit, QoS (Quality of Service) und das sogenannte Policy-Handling werden hier nicht oder nur am Rande behandelt. Ein weiteres Ziel diese Artikels ist auch, mit Blick auf die „Ahnentafel“ von IMS zu verstehen, wieso gewisse Mechanismen in dem NGN-Standard so eingeführt wurden und warum sie zur außerordentlichen Flexibilität von IMS beitragen. 1 Standardisierung 1.1 UMTS- und 3GPP-Vorgeschichte Im Rahmen der UMTS-Standardisierung für Mobilfunknetze der dritten Generation war das Standardisierungsgremium 3GPP (www.3gpp.org)sehr schnell davon abgekommen, Dienste im neuen UMTS-Vermittlungsnetz über das bei GSM bereits erreichte Niveau hinaus zu spezifizieren. Die Hauptgründe dafür waren einerseits, daß die in der Mobilvermittlungsstelle „hart-codierten“ Dienste mit GSM und CAMEL bereits ausreichend detailliert festgelegt waren. Andererseits wurde von allen Beteiligten erwartet, daß der eigentliche Entwicklungsschub im All-IP-Bereich stattfinden würde und demzufolge standardisierte Anwendungen und Dienste eher für die durch UMTS bereitgestellte mobile, breitbandige IP-Verbindung gebraucht würden. 1.2 IMS entsteht So war IMS ursprünglich als neues „Service Network” für IP-basierte UMTS-Netze gedacht und wurde von 3GPP als Teil seiner Standardisierungsausgabe 3GPP R5 (2003) spezifiziert. Da IMS IP-basierte Multimedia-Dienste handhaben sollte, war es naheliegend, auf diesbezügliche IETF-RFCs (SIP, SDP, DIAMETER usw.) zurückzugreifen (www.ietf.org). Diese von vornherein in den IMS-Standard eingebaute Multimedia-Fähigkeit macht einen großen Teil der Flexibilität von IMS aus. Der zunächst sehr akademische Ansatz wurde in der nächsten Ausgabe überarbeitet (3GPP R6, 2005). Mehrere Verbesserungen und Erweiterungen im Standard (IPv4 und IPv6 statt nur IPv6, Definition der Schnittstellen zu anderen TDM- oder IP-basierten Netzen) verbreiterten die tatsächlichen Einsatzmöglichkeiten von IMS.

Die IMS-Standardisierung beschreibt ein IMS Core Network für die Steuerung von Multimedia-Sessions, das alle Arten von Multimedia-Diensten parallel handhabt, sowie einen flexiblen Application-Server-Mechanismus (AS), bei dem über definierte, offene Schnittstellen zum IMS Core Network die eigentlichen Dienste von Anwendungsservern erbracht werden. Dabei sind im wesentlichen die Signalisierungs-, Transport- und Sicherheitsmechanismen für Echtzeit-, Messaging- und Presence-Dienste beschrieben worden (die sog. Enabler), nicht aber die Dienste selbst. Mittlerweile kümmert sich allerdings die Open Mobile Alliance (OMA, www.openmobilealliance.org) um die weitgehende Standardisierung der Applikationsmechanismen. 1.3 IMS als Festnetz-NGN-Standard Spätestens als man bei 3GPP begann, für die nächste Ausgabe des Standards (3GPP R7, Standardisierung andauernd) IMS als verallgemeinertes IP-basiertes Vermittlungsnetz zu definieren, das durchaus auch mit Zugangsnetzen ganz anderer Art (z.B. nach 802.11 oder .16 Standards wie WLAN/Wimax oder auch DSL- oder Ethernet-basiert) zusammenarbeiten könnte, wurde man bei ETSI hellhörig. Die für Festnetzstandardisierung zuständige Behörde hatte bereits jahrelang in verschiedenen Gruppen (ETSI TIPHON, ETSI SPAN, 2003 zusammengefaßt zu ETSI TISPAN) über die Standardisierung der Next Generation Networks für Festnetze nachgedacht, war aber zu keinem finalen Ergebnis gekommen. Da ohnehin auch bei ETSI (bzw. im für NGN zuständigen Technical Comittee TC TISPAN) über Themen wie „Mobilität im Festnetz“ und „konvergente Netze“ nachgedacht wurde, fiel die Adaption eines ursprünglichen „Mobilfunk“-Standards nicht schwer. ETSI TISPAN begann, eng mit relevanten 3GPP-Arbeitsgruppen zusammenzuarbeiten. Ende 2005 hatte dann auch das Festnetz seinen IMS-basierten NGN-Standard: In ETSI TISPAN R1 wurde die IMS-Struktur verallgemeinert, basierend auf den 3GPP-Spezifikationen. An vielen Stellen übernahm man 3GPP-Spezifikationen komplett, einige wenige wurden an speziellen Bedürfnisse eines breitbandigen, mehrere parallele Anwendungen unterstützenden IP-Zugangsnetzes angepaßt. Zusätzlich erlaubt es die subsystembasierte Struktur auch zukünftige Entwicklungen und Erweiterungen mit in die verallgemeinerte Architektur einzubeziehen. 1.4 FMC und Hyper-Konvergenz Damit haben zum ersten Mal in der Geschichte die wichtigsten ITK-Gremien an einem Standard zusammengearbeitet: IETF, die Internet Engineering Task Force, die für viele in 3GPP referenzierten RFCs zuständig ist, 3GPP für die Mobilfunksparte sowie ETSI TISPAN für die Festnetze. Dieser bisher einmalige Vorgang unterstreicht eindrucksvoll, daß bereits auf Standardisierungsebene der Anspruch von IMS als universellem NGN- und Hyper-Konvergenz-Standard sichergestellt wird. 2 Überblick über die IMS-Netzelemente 2.1 Netzarchitektur Bild 1 zeigt den Überblick über eine IMS-Netzarchitektur. Im folgenden wird kurz auf die Funktionen der einzelnen IMS-Systemkomponenten eingegangen.

UAUAUA

UAUAUA

Bild 1: IMS Netzarchitektur im Überblick 2.2 IMS Netzknoten 2.2.1 UA Der User Agent (UA) ist die universelle IMS-Bezeichnung für einen Endpunkt, der an der SIP-Signalisierung teilnimmt. Im einfachsten Fall wäre dieses ein SIP-Telefon oder ein Softclient auf einem Computer. Es ist aber auch möglich, daß z.B. ein Application Server diese Rolle einnimmt und wie ein UA signalisiert. 2.2.2 CSCF Der Call Session Control Server (CSCF) ist das zentrale Element der IMS-Architektur. Er baut auf dem Prinzip klassischer Softswitche auf, hat diesen allerdings zwei Hauptvorteile voraus. Zum einem bietet er eine Multimedia-Fähigkeit im Gegensatz zu der reinen Sprachfunktionalität der Softswitche. Zum anderen verfügt er über offene, standardisierte Schnittstellen zu Teilnehmerdatenbank und Anwendungsservern, was das System flexibel gegenüber Anwendungserweiterungen macht. Der CSCF kommt in drei Ausprägungen vor: Proxy (P), Interrogating (I), and Serving (S). 2.2.2.1 P-CSCF Dies ist der erste Kontaktpunkt innerhalb des IMS-Netzes für ein IMS User Agent (UA). Über das zugrundeliegende IP-CAN (IP Connectivity Access Network, z.B. der Breitbandzugang im Festnetz oder GPRS im Mobilnetz) wird zunächst eine IP-Verbindung geschaffen, auf der die SIP-Signalisierung dann aufsetzt. Aufgrund seiner Rolle als „Torwächter“ für das IMS-Netz

erfüllt der P-CSCF viele Sicherheitsfunktionen und sichert nach erfolgreicher Authentifizierung den anderen IMS-Knoten im Netz die festgestellte Identität des Users zu, so daß andere Knoten dieses nicht wiederholen müssen. 2.2.2.2 I-CSCF Der Interrogating CSCF wird als Einstiegspunkt in eine administrative Domäne eingesetzt (nur für kommende Anfragen). Beispiele sind die Bestimmung des aktuellen S-CSCF des Nutzers oder die Registrierung eines roamenden SIP-Nutzers. In beiden Fällen ist nämlich (noch) nicht bekannt, welcher von möglicherweise mehreren S-CSCFs den Nutzer tatsächlich verwaltet. Zu diesem Zweck führt der I-CSCF eine Abfrage des HSS durch, welcher S-CSCF dem Nutzer bereits zugeordnet ist, bzw. führt die Zuordnung durch, falls dieses bisher noch nicht geschehen ist. Der Vorteil der I-CSCF-Funktion liegt darin, daß im Interworking-Fall zwischen zwei IMS-Netzen das abgebende Netz die Anzahl und Kennungen der HSS und CSCF des empfangenden Netzes nicht zu kennen braucht (oder dieses auch gar nicht darf), sondern nur die des I-CSCF. Konkret versteckt man damit die Topologie des Empfängernetzes, was der Sicherheit jedes einzelnen Netzbetreibers und der Verminderung des Koordinationsbedarfes untereinander dient. 2.2.2.3 S-CSCF Der Serving CSCF basiert auf der SIP-Registrar-Funktion und ist damit für die Dienste- und die Session-Abwicklung des Users zuständig. Der S-CSCF ist daher die wichtigste aller drei CSCF-Ausprägungen. Nach der Allokation eines S-CSCF zu einem Benutzer lädt der S-CSCF die User-Daten vom HSS (z.B. welche kommenden und gehenden Zusatzdienste für diesen User gelten) und meldet diesen User beim HSS als zu diesem S-CSCF gehörig an (für eventuelle zukünftige Abfragen durch das I-CSCF). Zwei weitere wichtige Funktionen zeigen die zentrale Rolle des S-CSCFs beim Session-Aufbau: IP-Adressen-Bindung und SIP-Routing. Unter ersterem versteht man die paarweise Speicherung von öffentlicher SIP-ID des Users (Public ID, siehe Kapitel 3) und seiner gegenwärtigen Kontaktadresse (z.B. der IP-Adresse seines gerade benutzten Terminals). Letztere beinhaltet das Auffinden des gewünschten B-Teilnehmers. Hierzu benötigt der S-CSCF zwei unterschiedliche Hilfsfunktionen (DNS/Enum), je nachdem ob die B-Teilnehmerkennung eine SIP-Identität oder eine herkömmliche Telefonnummer (E.164) ist (IMS-Adressierungsarten werden in Kapitel 3 erklärt). Zusätzlich muß der S-CSCF im E.164-Fall zunächst eine B-Nummern-Normalisierung durchführen, um eine Eindeutigkeit der E.164-Nummern zu gewährleisten. 2.2.3 DNS/Enum Beim Auffinden des B-Teilnehmers kann es ja nach Art der Identität, die der A-Teilnehmer angegeben hat, zwei verschiedene Fälle geben. Im Fall einer SIP-Kennung (IMS-Adressierungsarten werden in Kapitel 3 erklärt) muß aus der Domäne des Adressaten eine erste Adresse des Netzes des Adressaten abgeleitet werden. Hierfür wird ein DNS-System benötigt, das für einen gegebenen Fully Qualified Domain Name (FQDN) ein Routing angeben kann. Ist die angegebene Kennung des Adressaten eine herkömmliche Telefonnummer, wird ein Enum-System benötigt, das eine gewählte E.164-Nummer in eine SIP URI umsetzen kann. 2.2.4 HSS, SLF HSS steht für Home Subscriber Server. Seine Aufgabe ist die Speicherung aller Teilnehmerdaten, die für den Aufbau von Multimedia-Verbindungen notwendig sind (z.B. Identität, Authentifizierungsdaten, eingerichtete Dienste usw.). Auf Anfrage stellt das HSS die relevanten

Daten anderen Netzelementen zur Verfügung (I-CSCF, S-CSCF, AS). Das HSS ist vergleichbar mit dem HLR in Mobilfunknetzen. Für den Fall, daß der Netzbetreiber mehr als ein HSS verwendet, wird eine Subscriber Locator Function (SLF) benötigt. Diese stellt eine Beziehung zwischen der Identität des Teilnehmers und dem HSS her, in dem seine Daten gespeichert sind. 2.2.5 AS Der Application Server (AS) ist die dienstegebenden Plattformen im IMS, nicht unähnlich zum IN der leitungsvermittelten Netze. Genau wie beim IN können die Dienste der AS im allgemeinen Fall sowohl auf der abgehenden wie auch auf der kommenden Seite angelegt werden. Auf einem Application Server können auch neue IMS-Dienste kreiert werden, wobei der Netzbetreiber oder der Anwendungslieferant völlig frei in der Ausprägung der Dienste ist. Neben den AS, die ganz spezifische IMS-Dienste offerieren, gibt es auch noch AS, die letztendlich nur eine Schnittstelle zur „alten Welt“ herstellen (also zum IN, dies ist die Rolle des IM-SSF in Bild 1, oder zur OSA/Parlay-Plattform, siehe OSA-SCS in Bild 1). 2.2.6 MRF Für einfache Dienste reicht es dem AS aus, nur die SIP-Signalisierung zu verändern, um den Dienst zu erbringen, z.B. für einen Session-Umleitungsdienst. Im allgemeinen jedoch möchte man auch die Medienebene beeinflussen können. Ein Beispiel sind Ansagen oder Signaltöne zum Endkunden; ein anderes eine Videokonferenz, in der nach einem bestimmten Schema für jeden Teilnehmer die Videobilder aller anderen Teilnehmer gruppiert und zusammen angezeigt werden. Solche Aufgaben übernimmt die Media Resource Function. Da die Manipulation der Nutzdatenebene eng mit der Signalisierung des Dienstes koordiniert werden muß, kann die MRF vom AS gesteuert werden. Mitunter wird innerhalb der MRF zusätzlich noch unterschieden in eine Steuerungsfunktion MRFC (MRF Controller) und eine Nutzdatenfunktion MRFP (MRF Processor). 2.2.7 MGW/MGC/SGW Die funktionalen Einheiten Media GateWay, Media Gateway Controller und Signaling GateWay sind für die Übergabe einer Session zwischen der IMS-Domain mit SIP-Signalisierung und einem leitungsvermitteltem TDM-Netz mit ISUP zuständig (PSTN, PLMN) – in beide Richtungen. Der MGC wählt ein passendes MGW aus, das wiederum Ressourcen zur Wandlung der Nutzdatenebene für die gegenwärtige Session zur Verfügung stellt (RTP <-> TDM). Die Wandlung von gesprächsbezogener SIP-Signalisierung in IMS von und nach ISUP stellt das SGW zur Verfügung. 2.2.8 Weitere Knoten Weitere wichtige Knoten sind die Break-Out Gateway Control Function (BGCF), deren Aufgabe die Auswahl des richtigen MGC im Fall einer PSTN-Terminierung ist, sowie das Session Border Gateway, das an Netzschnittstellen (zu anderen Netzen, oder zum Zugangsnetz) für Sicherheitsfunktionen eingesetzt wird. 3 IMS Adressierung 3.1 SIP-Adressen, SIP URIs Wie wir später sehen werden, ist SIP das Signalisierungsprotokoll, das eine zentrale Rolle im IMS einnimmt. Es ist daher notwendig, die Adreßformate im SIP etwas genauer zu betrachten.

Die im SIP verwendeten Adressen heißen SIP URIs (Uniform Resource Identifier). Gemäß [1] besteht eine SIP URI aus dem Kennwort sip:, einer Kennung der Form user@host oder user@domain sowie einer optionalen Parameterliste. Dabei ist der user@-Teil strenggenommen optional, und der host- oder domain-Teil muß den SIP-Server oder die SIP-Ressource identifizieren, und zwar entweder über eine numerische IP-Adresse oder über ein FQDN (Fully Qualified Domain Name). Beispiel:

sip: server1@domain.com sip: mainsipserver sip: 192.168.2.1 sip: jens.andresen@ericsson.com sip: 492115341260@ericsson.com;user=phone

wären somit alles legale SIP URIs. 3.2 TEL URL Die TEL URL ist ein anderes Format, das zur Adressierung im SIP verwendet werden darf. Es wurde geschaffen, um die Kommunikation zwischen IMS-Nutzern und denen herkömmlicher Netze zu ermöglichen. Zur Adressierung von Nicht-IMS-Nutzern aus einem IMS heraus werden E.164-Rufnummern benötigt, die keinen Domain-Namen enthalten. Andererseits kann eine Teilnehmeradressierung von einem herkömmlichen Telefon aus nur Ziffern enthalten. Zur Kennzeichnung wird die TEL URL mit dem Präfix tel: versehen, gefolgt von der Telefonnummer im internationalen Format. Beispiel: tel: +49-211-534-1260. 3.3 Endbenutzeradressierung Ähnlich zu heute existierenden Mobilfunknetzen werden im IMS zwei Arten von Benutzeridentitäten vergeben, die öffentliche und die private Adresse (Public ID, Private ID). Hierbei ist erstere die von anderen Benutzern eingegebene ID, die vom Netz verwendet wird, um den Session-Anfrage richtig zu vermitteln (analog zur MSISDN in Mobilfunksystemen). Letztere dient als netzinterne Verzeichnisnummer des Teilnehmers (analog zur IMSI in Mobilfunksystemen). Trotz der hier gezogenen Parallele zu Mobilfunknetzen ist es wichtig zu berücksichtigen, daß die Public/Private ID universelle IMS-Mechanismen sind, die unabhängig vom Zugangsnetz benutzt werden. 3.3.1 Public ID Die öffentlich verwendete Identität des Teilnehmers, also die weitergegebene oder auf Visitenkarte gedruckte Teilnehmeradresse, ist durch die Public ID gegeben, die verschiedene Formen annehmen kann. 3.3.1.1 SIP URI Als Public ID kann die schon aus Kapitel 3.1 bekannte SIP URI verwendet werden. Sie hat dann die aus E-Mail-Adressen bekannte Struktur user@domain, versehen mit dem Kennwort sip:: Beispiel: sip:jens.andresen@ericsson.com oder sip:+49-211-534-1260@operator.de; user=phone

Die zweite Adresse ist dabei ein Beispiel für die in Kapitel 3.1 genannte optionale Parameterliste ;user=phone. 3.3.1.2 TEL URL Als Public ID kann auch die schon aus Kapitel 3.2 bekannte TEL URL verwendet werden. Beispiel: tel: +49-211-534-1260. 3.3.2 Private ID Die Private ID dient nicht zur Verbindungsherstellung mit dem Teilnehmer, sondern sie wird, wieder analog zur IMSI im GSM/UMTS-Mobilfunknetz, zur Identifizierung der Subskription bzw. zur Authentifizierung des Teilnehmers herangezogen. Dementsprechend muß sie auch Anrufern (oder dem Teilnehmer selbst) gar nicht bekannt sein. 3.4 Adressierung von IMS-Knoten Alle IMS-Netzknoten, die SIP-Signalisierung verwenden, also CSCF (alle drei Ausprägungen), AS, sowie die Break-out Gateway Control Function und die Media Gateway Control Function werden ebenfalls über SIP URIs adressiert [5]. Außerhalb eines Netzes würden im allgemeinen Fall jedoch nur die SIP URI im DNS veröffentlicht werden, die benötigt werden, um einen Kontakt zu diesem Netz herzustellen, also nur die der I-CSCFs, die die Netztopologie nach außen hin verstecken, bzw. die der P-CSCFs als erster Kontakt für die UA. 4 Signalisierung SIP (Session Initiation Protocol) ist ein flexibler Mechanismus zum Aufbau und zur Steuerung von Multimedia-Sessions, egal ob diese Sessions eine Audio-, Video-, Messaging-, Whiteboard-Verbindung oder alle Elemente gleichzeitig oder in einer von den Endbenutzern in Echtzeit gesteuerten Abfolge enthalten. Dabei überläßt gemäß IMS-Standard das SIP-Protokoll die eigentliche Beschreibung der Multimedia-Session einem anderen Protokoll, nämlich dem SDP (Session Description Protocol). Die eigentlichen Nutzdaten werden dann über das Protokoll RTP (Real-Time Protocol) ausgetauscht. 4.1 SIP 4.1.1 Überblick SIP ist ein textbasiertes Protokoll ähnlich zu HTTP. Genau wie HTTP ist auch SIP ein Request-Response-Protokoll. Ein Client sendet einen SIP-Request, und der Server antwortet mit einer SIP-Response. Anders als bei HTTP aber kann bei SIP jede Seite Client oder Server sein, je nachdem welche Seite eine Session oder Veränderungen daran initiiert. Die jeweilige Rolle eines UAs wird daher oft mit den Abkürzungen UAC (User Agent Client) und UAS (User Agent Server) gekennzeichnet. Tabelle 1: Liste der SIP Request Methoden SIP-Request-Methode Erklärung ACK bestätigt den Empfang der Sessioneröffnung (bestätigt ein OK) BYE Anfrage zur Terminierung einer Session (Gegenteil von INVITE) CANCEL Anforderung, die vorherige Anfrage abzubrechen INFO Anfrage, mit der PSTN-bezogene Informationen übermittelt werden INVITE „Einladung“ zu einer Session, oder zu einer Modifizierung der

Session NOTIFY Benachrichtigung über eine Änderung im Verfügbarkeitszustandes

(Presence) eines Teilnehmers, dessen Presence man abonniert hat MESSAGE Anforderung zur Direktübertragung einer Instant Message OPTIONS Anfrage an einen Server, seine Fähigkeiten (Options) darzulegen PRACK Bestätigt eine vorläufige Antwort (PRovisional response

ACKnowledgement) PUBLISH ein SIP UA gibt über die Publish-Anfrage seinen

Verfügbarkeitszustand (Presence) bekannt REGISTER Anforderung, einen User Agent erstmalig oder wiederholt beim

System zu registrieren REFER Anforderung an einen Server, einen neuen oder modifizierten

Request zu senden (zur Umleitung von SIP-Signalen verwendet) SUBSCRIBE Anforderung, über den Verfügbarkeitszustand eines Teilnehmers

(Presence) informiert zu werden (subscribe = abonnieren) UPDATE modifiziert gewisse Eigenschaften einer Session

Bemerkung: Nur ACK, BYE, CANCEL, INVITE, OPTIONS, REGISTER entstammen dem ursprünglichen SIP RFC [1], die anderen SIP-Methoden entstammen SIP-Erweiterungen. 4.1.2 SIP-Anfragen und -Antworten Welche Art von Anfragen (Requests) und Antworten (Responses) gibt es in SIP? Gegenwärtig sind die in Tabelle 1 gezeigten SIP-Request-Methoden (Methods) definiert. Die entsprechenden Antworten auf diese Signale sind bewußt vielfältig spezifiziert, um im eventuellen Fehlerfall eine möglichst genaue Fehlerursache angeben zu können. Weiterhin sind die Antwortsignale in logisch zusammengehörige Klassen eingeteilt (zu erkennen daran, daß der Statuscode von Antworten innerhalb einer solchen Antwortklasse mit der gleichen Ziffer beginnt). Ein SIP-Antwortsignal enthält sowohl den numerischen Statuscode wie auch eine Klartexterklärung. Beispiel: „SIP/2.0 180 Ringing“ oder „SIP/2.0 183 Session progress“. Bemerkung: Die SIP-Version ist stets vorangestellt. Beides sind vorläufige Antworten und ihr Statuscode beginnt deswegen mit einer 1. Aufgrund der Vielzahl der möglichen Antwortsignale sollen hier daher nur die Antwortklassen aufgeführt werden, Tabelle 2. Tabelle 2: Klassen der SIP-Antwortsignale Statuscode-Bereich Erklärung 100-199 vorläufige Antworten (wie „SIP/2.0 180 Ringing“ im Beispiel oben) 200-299 erfolgreiche Antworten, z.B. „SIP/2.0 200 OK“, die Bestätigung 300-399 Statuscodes für Umleitungen (Re-Direction) 400-499 Client-Fehlerfälle 500-599 Server-Fehlerfälle 600-699 globaler Fehlerfall

4.1.3 SIP-Transaktionen Die verschiedenen SIP-Signale dürfen nicht beliebig miteinander kombiniert werden, sondern es gibt vorgegebene SIP-Transaktionen (Kombinationen aus Request und Response), deren Format eingehalten werden muß. Es gibt spezielle Transaktionen (beginnen mit INVITE, ACK oder CANCEL) und reguläre Transaktionen (alle anderen). Alle regulären Transaktionen bestehen aus einer Anforderung (Request), null oder mehr vorläufigen Antworten (Statuscode 1xy) und einer finalen Antwort. Die speziellen Transaktionen weichen von diesem Schema individuell ab. 4.2 SDP SDP (Session Description Protocol, [3]) ist ebenfalls ein textbasiertes Protokoll, im wesentlichen sogar nur eine textbasierte Beschreibung einer Session. SDP enthält eine exakte Beschreibung der aufzubauenden Session. Hierzu gehören z.B. die Medienbeschreibungen, Codecs, Ports, Senderichtungen usw. Dieses erfolgt durch eine Liste von SDP-Typen und ihren jeweiligen Werten im festgelegten Format Typ = Wert, wobei Typ durch einen einzigen Buchstaben gegeben ist. Beispiel einer Session-Beschreibung mit SDP: v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=discussion of the sdp c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 m=audio 49170 RTP/AVP 0 a=sendrecv m=video 51372 RTP/AVP 31 a=sendrecv Hier wird z.B. Information über - die SDP-Version (v=); - den Namen der Session (s=); - die Verbindung an sich (über das Internet unter Benutzung von IPv4, enthalten im c=-Typ); - Start- und Endzeit (t= im NTP-Format); - den Audio- bzw. Video-Port (m=audio <port number> bzw. m=video <port number>); - die verwendeten Codecs (RTP/AVP 0 entspricht G.711µ-law, RTP/AVP 31 entspricht H.261 video codec); - den Duplex-Modus (Full-Duplex, jeweilige Attributzeile a=sendrecv) gegeben. Eine vollständige Beschreibung von SDP findet sich in [rfc4566], allerdings wird in IMS nur ein bestimmter Teil davon verwendet, siehe [24.229]. 4.3 DIAMETER DIAMETER ist definiert als ein AAA-Protokollmechanismus(Authentication, Authorization, Accounting), auf dem nach Bedarf Anwendungen definiert werden können. Im IMS findet es Anwendung bei benutzerbezogenen Anfragen zum HSS (Cx-, Dx-Referenzpunkt), sowie als Credit-Control-Protokoll zwischen den IMS-Knoten und dem Vergebührungssystem.

DIAMETER ist definiert in [2]. Seine Anwendung im IMS finden sich in verschiedenen Spezifikationen, z.B. in [9], [10] für den Cx-Referenzpunkt oder in [11] für DIAMETER-basierte Vergebührungsanwendungen. 4.4 Protokolle zum Austausch der Nutzdaten 4.4.1 Übersicht Im IMS werden Nutzdaten über das Real-time Transmission Protocol (RTP) ausgetauscht, unterstützt durch das Real-time Transmission Control Protocol (RTCP), Bild 2. Dieses passiert dann über reguläre Transportmechanismen des zugrundeliegenden IP-Netzes und nicht über die Stationen der SIP-Signalisierung. Dabei werden die vorher über SDP ausgetauschten IP-Adressen und -Ports verwendet.

IP

UDP

RTP

RTCP

Payload formats

Audio Video Text

Conversational Multimedia Application

Bild 2: Protokollaufbau für Multimedia-Echtzeitdienste

4.4.2 RTP Das Real-time Transmission Protocol wird verwendet, um Medienströme in Echtzeit über Transportmechanismen zu bewegen, die im Prinzip als unzuverlässig angesehen werden müssen. Die Mediendaten werden in Abschnitte unterteilt und in den Nutzdatenbereich des RTP-Pakets, zusammen mit begleitenden Informationen untergebracht: - Zeitstempel; - laufende Nummer; - Absenderkennung; - Typ der Nutzdaten. Der Zeitstempel ist eine Kennung der internen Aufteilung des Medienstroms in Pakete. Diese Angabe ist besonders im Zusammenhang mit RTCP wichtig. Die laufende Nummer erlaubt dem Empfänger eine genaue Sortierung der Reihenfolge, sowie eine Bestimmung eventuell fehlender Pakete. Die Absenderkennung ist für Konferenzen wichtig, und der Typ der Nutzdaten ist der über SDP vereinbarte payload type (siehe Kapitel 4.2), z.B. RTP/AVP 0 oder RTP/AVP 31. 4.4.3 RTCP Das Real-time Transmission Control Protocol wird immer zusammen mit RTP verwendet, um wichtige Kontrollinformationen über den RTP-Strom zu übermitteln. Hierzu gehören

- eine Übersetzung der medienstromspezifischen Zeitstempel in absolute Zeitangaben (z.B. zur Synchronisierung verschiedener Medien untereinander); - die Übersetzung der (binären) RTP-Absenderkennung in ein Klartextformat; - das Zählen der gesendeten und empfangenen RTP-Pakete, um die Paketverlustrate einer Session bestimmen zu können. Für reine Punkt-zu-Punkt-Sprachverbindungen über RTP (und nur für diese) darf RTCP weggelassen werden. 5 Verkehrsfälle 5.1 IMS Registrierung 5.1.1 Entdeckung des P-CSCF Bevor ein SIP UA mit der SIP-Signalisierung beginnen kann, muß zunächst der zuständige P-CSCF entdeckt werden, der (siehe Kapitel 2.2.2.1) den Eintrittspunkt in die IMS-Domäne darstellt. Dies kann auf ganz unterschiedliche Weise erreicht werden und hängt auch vom Zugangsnetz ab. Es gibt drei Möglichkeiten: - Integriert in die Anmeldung beim IP-CAN (z.B. kann bei einer DHCP-Anfrage eine Liste von P-CSCF-Domains mitgeliefert werden); - als separate DHCP-Anfrage nach einer Liste von P-CSCF-Adressen, nachdem die IP-CAN-Registrierung abgeschlossen ist; - voreingestellt im SIP UA. 5.1.2 Registrierung auf IMS Ebene Nachdem das IMS-Terminal seinen Eintrittspunkt in das IMS-Netz entdeckt hat, muß es sich registrieren, bevor es Sessions aufbauen oder andere SIP-Aktionen ausführen kann. 5.1.2.1 Ziel der Registrierung Das Ziel der Registrierung ist es, eine eindeutige Verbindung zwischen dem gegenwärtig genutzten SIP UA und der der Public ID des Benutzers zu erzeugen. Da die Adressierung eines Benutzers immer über seine Public ID erfolgt (siehe Kapitel 3.3.1), andererseits aber die gerade benutzte IP-Adresse immer unterschiedlich sein kann (Client-Mobilität ist gegeben), muß das IMS an einer Stelle die Verbindung zwischen der Public ID und der aktuellen IP-Adresse oder der aktuellen FQDN speichern. Diese Funktion des Binding ist dem S-CSCF zugewiesen, der im allgemeinen Fall jedoch erst einmal gefunden werden muß. Andere Aufgaben der Registrierung sind gegenseitige Authentifizierung von IMS-Terminal und IMS-Netz sowie weitere Sicherheitsmechanismen. 5.1.2.2 Verlauf der Registrierung Die Registrierung wird durch eine SIP-REGISTER-Nachricht vom SIP UA an den P-CSCF angestoßen (siehe Bild 3) (1). Wir nehmen an, daß der User Agent in einem besuchten Netz agiert, so daß der P-CSCF mit dem Heimatnetz des Benutzers Kontakt aufnehmen muß. Dieses geschieht über eine (mehrfache) DNS-Abfrage, bei der der P-CSCF die Adresse eines I-CSCF im Heimatnetz des Benutzers zugewiesen bekommt (2, 3). Der P-CSCF leitet die Nachricht an einen I-CSCF weiter, der auf jeden Fall im Heimatnetz des Nutzer liegt (4). Der I-CSCF fungiert somit als Eintrittspunkt für das Heimatnetz des Nutzers, genau wie der P-CSCF als Eintrittspunkt in die IMS-Domäne insgesamt fungiert. Die Aufgabe des I-CSCF ist die Auswahl des richtigen S-CSCF. Hier gibt es zwei Möglichkeiten, zum einen, daß dem Benutzer schon ein S-CSCF zugewiesen wurde, oder zum anderen, daß noch keiner für diesen Benutzer allokiert wurde. Welche der beiden Möglichkeiten zutrifft, erfährt der

I-CSCF über eine Abfrage des HSS (5). Im ersten Fall wird die Anfrage mit der Adresse des zugewiesenen S-CSCF beantwortet, im zweiten mit einer Liste von Kriterien, die der I-CSCF bei der Auswahl eines geeigneten S-CSCFs berücksichtigen muß. Im Bild 3 wird vom zweiten Fall ausgegangen (6). Der I-CSCF wählt dann einen entsprechenden S-CSCF aus und leitet daraufhin die REGISTER-Anfrage an den ausgewählten S-CSCF weiter (7).

(1)R

EGIS

TER

(1)R

EGIS

TER

Besuchtes Netz Heimat-Netz

UA

I-CSCF

I-CSCF

S-CSCF

S-CSCF

S-CSCF

HSSDNS

(4)REGISTER(4)REGISTER

(7)REGISTER

(7)REGISTER

(10) 401 UNAUTH.

(10) 401 UNAUTH. S-CSCF

(11) 401 UNAUTH.

(11) 401 UNAUTH.

(12)

401

UN

AUTH

.

P-CSCF

(2)“DNS query“

(3)“home I-C

SCF“

(2)“DNS query“

(3)“home I-C

SCF“

(5)“H

SS q

uery

“(6

) “req

. cap

‘s. “

(5)“H

SS q

uery

“(6

) “req

. cap

‘s. “

(8)“HSS query“

(9)“sub.auth.data“(8)“H

SS query“

(9)“sub.auth.data“

Bild 3: Registrierung eines SIP User Agents, Teil 1 Nun ist endlich der finale Adressat für die REGISTER-Nachricht gefunden. Der ausgewählte S-CSCF kontaktiert das HSS (8), um seine Rolle als für diesen Benutzer zuständigen S-CSCF speichern zu lassen (für eventuelle nächste I-CSCF-Anfragen beim HSS), und um die sog. Authentication Vectors für eine zweifelsfreie Authentifizierung herunterzuladen (wir gehen von dem Fall aus, daß der Benutzer noch nicht registriert war) (9). Danach wird zunächst die REGISTER-Nachricht des Endgeräts negativ beantwortet (SIP/2.0 401 Unauthorized), allerdings enthält diese Ablehnung eine Sicherheitsabfrage (10, 11, 12). Das IMS-Terminal kann bei Erhalt dieser Nachricht die Sicherheitsabfrage extrahieren, sie mit Hilfe seiner lokalen Authentifizierungsdaten beantworten und diese Antwort dann in einem erneuten REGISTER über P-CSCF und I-CSCF an den S-CSCF senden (siehe Bild 4). Der S-CSCF überprüft die Antwort auf die Sicherheitsabfrage, lädt bei richtiger Antwort die Endbenutzerdaten vom HSS herunter und bestätigt dem Terminal die erfolgreiche Registrierung mit SIP/2.0 200 OK, siehe Bild 4. An dieser Stelle ist die Registrierung erfolgreich beendet. Der Signalisierungsverlauf ist im Prinzip der gleiche wie in Bild 3, allerdings mit folgenden wichtigen Unterschieden:

- Der I-CSCF könnte ein anderer sein als beim ersten Mal, z.B. wenn der Netzbetreiber aus Gründen der Redundanz oder Lastverteilung weitere I-CSCFs definiert hat und die DNS-Abfrage die Adresse eines anderen I-CSCF als beim ersten Mal ergab. - Die I-CSCF-Signalisierung zum HSS dient nicht dazu, die Anforderungen an einen auszuwählenden S-CSCF herunterzuladen (wie im Fall der Erstregistrierung), sondern ergibt jetzt als Resultat die Adresse des bereits im ersten Schritt ausgewählten S-CSCF. - Die S-CSCF-Signalisierung zum HSS dient nicht – wie beim ersten Mal – zum Registrieren des S-CSCFs für diesen Benutzer, sondern zur erfolgreichen Registrierung des Benutzers selbst. Als HSS-Antwort werden nicht die Authentifizierungsdaten heruntergeladen, sondern alle Teilnehmerdaten, die der S-CSCF zur Handhabung dieses Teilnehmers braucht. - Die Rückantwort an den UA ist nicht negativ, sondern positiv (200 OK, erfolgreiche Authentifizierung vorausgesetzt).

(1)R

EGIS

TER

(1)R

EGIS

TER

Besuchtes Netz Heimat-Netz

UA

I-CSCF

S-CSCF

S-CSCF

S-CSCF

HSSDNS

(7)REGISTER

(7)REGISTER(10) 200 OK

(10) 200 OK S-CSCF

(4)REGISTER

(4)REGISTER

(11) 200 OK

(11) 200 OK

(12)

200

OK

P-CSCF

(2)“DNS query“

(3)“home I-C

SCF“

(2)“DNS query“

(3)“home I-C

SCF“

(8)“HSS query“

(9)“sub.data“(8)“H

SS query“

(9)“sub.data“

I-CSCF

(5)“H

SS q

uery

“(6

) “S-C

SCF “

(5)“H

SS q

uery

“(6

) “S-C

SCF “

Bild 4: Registrierung eines SIP User Agents, Teil 2 5.1.2.3 Endbenutzerdaten im S-CSCF Die Endbenutzerdaten enthalten zwei wichtige Datengruppen: die Public IDs, die für diesen Nutzer gelten, die implizit mitregistrierten Public IDs sowie die sog, Filterkriteren (Filter Criteria). Letztere geben Aufschluß darüber, in welchen Fällen ein Application Server in die Session miteinbezogen wird, und lassen sich am besten mit IN-Triggern in intelligenten Netzen vergleichen. Optional kann das OK-Signal (siehe Bild 4, (10, 11, 12) ) die Information enthalten, welche SIP-Server in zukünftigen Signalisierungen zwischen P-CSCF und S-CSCF mit eingeschlossen sein sollen, gängige Möglichkeiten sind entweder eine direkte P-CSCF-zu-S-CSCF-Kommunikation oder die Beibehaltung der P-CSCF/I-CSCF/S-CSCF-Reihenfolge.

5.1.2.4 Bemerkungen zur IMS-Registrierung Beim Vergleich dieser Prozedur mit Vorgängen in heutigen Netzen fällt die Ähnlichkeit zum Location Update in Mobilfunknetzen auf. Es soll hier aber davor gewarnt werden, dies dahingehend zu interpretieren, daß das IMS nur für Mobilfunknetze geeignet sei. Im Gegenteil, dieser Registrierungsvorgang erfüllt wichtige Anforderungen, die auch ETSI an Next Generation Networks im Festnetz gestellt hatte, z.B. die Unterstützung für nomadische Anwendungsfälle (siehe auch Kapitel 1.2). Mit dem oben beschriebenen Vorgang kann ein Benutzer sich z.B. sowohl Zuhause mit seinem Laptop oder im Hotspot einloggen, sofern sein DSL-Betreiber Zuhause und der Hotspot-Betreiber sich darauf verständigt haben, daß ihre IMS-Netze von den Nutzern des jeweils anderen mitbenutzt werden dürfen. 5.2 SIP-SIP-Session 5.2.1 Die originierende INVITE-Anfrage Bild 5 zeigt den Aufbau einer Session zwischen zwei SIP-Teilnehmern, die nicht nur verschiedenen Netzen angehören, sondern auch noch in jeweils anderen IMS-Domänen als ihren Heimatnetzen unterwegs sind. An diesem allgemeinen Fall soll der SIP-Session-Aufbau im Überblick dargestellt werden. Zunächst sendet der UA(A) eine INVITE-Anfrage an seinen Proxy-Server, den es aus dem in Kapitel 5.1.1 beschriebenen Vorgang kennt (1). In diesem Fall hatte der S-CSCF bei Abschluß der Registrierung vorgeschrieben, daß der S-CSCF direkt kontaktiert werden soll, unter Auslassung eines I-CSCF im Heimatnetz, siehe auch Kapitel 5.1.2.3 (2) .

Gastnetz A Heimnetz A Heimnetz B Gastnetz B

(1)IN

VITE

(1)IN

VITE

UA (A)

(16)

SESS

ION

PRO

GR

ESS

(16)

SESS

ION

PRO

GR

ESS

P-CSCF S-CSCF

I-CSCF

HSS

S-CSCF

(11)SESSION

PRO

GR

ESS(11)SESSIO

N

PRO

GR

ESS

(10)INVITE

(10)INVITE

UA (B)

P-CSCF

(2)INVITE(2)INVITE

DNS

(5)INVITE

(5)INVITE

(6)HSS qu

ery

(7)S-C

SCF

(6)HSS qu

ery

(7)S-C

SCF

(8)INVITE

(8)INVITE (9)INVITE(9)INVITE

(12)SESSIONPROGRESS(12)SESSIONPROGRESS

(13)SESSION

PROGRESS

(13)SESSION

PROGRESS(14)SESSION

PROGRESS(14)SESSION

PROGRESS

(15)SESSIONPROGRESS(15)SESSIONPROGRESS

(3)D

NS q

uery

(4)te

rm.I-

CSC

F

(3)D

NS q

uery

(4)te

rm.I-

CSC

F

AS

(2a)INVITE

(2b)INVITE(2a)INVITE

(2b)INVITE

AS

(8a)INVITE

(8b)INVITE

(8a)INVITE

(8b)INVITE

Bild 5: SIP-zu-SIP-Session-Aufbau, Teil1

5.2.2 Aufgaben des originierenden S-CSCF Falls der S-CSCF an den Filterkriterien erkennt, daß ein Application Server eingeschaltet werden muß, wird die INVITE-Signalisierung durch den AS geschleift (2a, 2b). Nachdem die abgehenden Dienste durch diesen AS angelegt wurden, läuft die INVITE-Nachricht erneut durch den originierenden S-CSCF, der nun den Adressaten der INVITE-Nachricht ausfindig machen muß. Dieses passiert durch eine Reihe von DNS-Abfragen (3), mit deren Hilfe die Request URI, also die Adresse des IMS-Teilnehmers B, in eine IP-Adresse eines Servers verwandelt werden kann, der sich im Heimnetz des Adressaten befindet (4). Dieser Server wird normalerweise ein I-CSCF sein. Strenggenommen gilt es in diesem Schritt zu unterscheiden, ob die Request URI eine SIP URI oder TEL URL ist. Im letzteren Fall wird ein Enum-Server benötigt, der TEL URLs in die korrespondierenden SIP URIs umwandelt. Sollte das scheitern, so bleibt dem IMS-System im Heimnetz A nichts anderes übrig, als die Session-Anfrage an das PSTN abzugeben, in der Hoffnung, daß die angefragte Telefonnummer in den leitungsvermittelten Netzen bekannt ist. 5.2.3 Aufgaben des terminierenden I-CSCF Der I-CSCF im Heimatnetz des Benutzers B führt nun seine Aufgabe durch, nämlich das Auffinden des zu dem gesuchten Benutzer gehörenden terminierenden S-CSCF. Dieses geschieht durch eine HSS-Abfrage (6), die mit der Adresse des terminierenden S-CSCF beantwortet wird (7). Die letzte Aufgabe des terminierenden I-CSCF ist dann die Weiterleitung der INVITE-Anfrage an den terminierenden S-CSCF (8). 5.2.4 Aufgaben der terminierenden S-CSCF und P-CSCF Die Anfrage zum Session-Aufbau ist nun im S-CSCF des IMS-Teilnehmers B angekommen. Der S-CSCF muß nun die Filterkriterien dieses Teilnehmers für terminierende Dienste auswerten und bei Bedarf den AS einschalten (optional 8a, 8b). Der AS legt die entsprechenden Dienste für die ankommende Session an, und sendet die Anfrage weiter an den S-CSCF (ein einfaches Beispiel für einen terminierenden Dienst wäre eine Session-Umleitung, die durch eine entsprechende Modifizierung des INVITE-Signals im AS zu erreichen wäre). Da der S-CSCF nach der Registrierung die gegenwärtige Adresse des Benutzers sowie seines gültigen P-CSCFs enthält, kann der S-CSCF die INVITE-Anfrage an den gültigen P-CSCF weiterleiten (9). Der terminierende P-CSCF leitet dann die Session-Einladung an den terminierenden SIP UA weiter (10). 5.2.5 Verhandlung über die zu benutzenden Medien Die so durch das IMS-Netz geleitete SIP-INVITE-Nachricht enthält eine im SDP beschriebene gewünschte Session (siehe Kapitel 4.2). Der terminierende SIP UA prüft nun, ob er diese angefragten Medien unterstützen kann oder will. Dabei hat der empfangende Client die Möglichkeit, einen aus einer Reihe möglicher Codecs auszuwählen (falls der sendende Client z.B. mehrere alternative Audio-Codecs angeboten hat) oder nur einen Teil der angefragten Codecs zuzulassen (z.B. kein Video-, nur Audio-Codec). Erst wenn eine Einigkeit über die aufzubauende Session besteht und beide UA entsprechende Ressourcen reserviert haben, wird der Nutzer B benachrichtigt.

Die Annahme der gewünschten Session oder der entsprechende „Gegenvorschlag“ wird, wiederum in SDP beschrieben, als Teil einer 183-Session-Progress-Nachricht zum Absender der INVITE-Nachricht zurückgeschickt (Bild 5, 11-16). Wenn die SDP-Antwort des angerufenen Terminals vom anrufenden Terminal akzeptiert werden kann, so sendet dieses eine erneute Session-Beschreibung (die von beiden Seiten akzeptierte) innerhalb einer Zwischenbestätigung (PRACK, nicht gezeigt) und beginnt mit der Ressourcenreservierung auf seiner Seite. Das empfangende Terminal kann nach Erhalt der PRACK-Nachricht mit der abgestimmten Session-Beschreibung ebenfalls mit der Ressourcenreservierung beginnen und teilt dies dem Anrufer über eine OK-Nachricht mit (PRACK- und OK-Vorgänge nicht im Bild 5 gezeigt). Sobald das anrufende Terminal fertig ist mit der Reservierung der abgestimmten Codecs und Ports, sendet es dem Empfängerterminal eine UPDATE-Nachricht (siehe Bild 6, 1-5), die dieses mit OK beantwortet (Bild 6, 6-10).

Gastnetz A Heimnetz A Heimnetz B Gastnetz B

(1)U

PDAT

E(1

)UPD

ATE

UA

(10)

200

OK

(10)

200

OK

P-CSCF S-CSCF

I-CSCF

HSS

S-CSCF

(6)200 OK

(6)200 OK

(5)UPD

ATE(5)U

PDATE

UA

P-CSCF

(2) UPDATE(2) UPDATE

DNS

(9)200 OK(9)200 OK

(3) UPDATE(3) UPDATE

(8)200 OK(8)200 OK

(4) UPDATE(4) UPDATE

(7)200 OK(7)200 OK

Bild 6: SIP-zu-SIP Session Aufbau, Teil2

Das Empfängerterminal darf erst seinen Benutzer benachrichtigen, sobald die Ressourcen für die gewünschte Session reserviert sind, d.h., sobald es die UPDATE-Nachricht des anrufenden Terminals erhalten hat und seine eigenen Ressourcen reserviert sind. Wenn es mit dem Klingeln beginnt, schickt es eine 180-RINGING-Nachricht zum Anrufer, und sobald der Angerufene abnimmt, ein finales 200 OK, das das ursprüngliche INVITE beantwortet. Zu diesem Zeitpunkt sind sich originierendes und terminierendes Terminal einig darüber, welche Codecs verwendet werden sollen, die Ressourcen dafür sind von beiden reserviert und es sind die IP-Adressen und -Ports bekannt, über die mittels RTP und RTCP (siehe Kapitel 4.4) die Nutzdaten ausgetauscht werden sollen.

Es soll an dieser Stelle noch einmal betont werden, daß dieser Session-Aufbaumechanismus überhaupt keine Annahmen über die Art der zustandegekommenen Session noch über die darin verwendeten Multimedia-Elemente gemacht hat. Das bedeutet, daß der beschriebene Ablauf für eine einfache VoIP-Sprachverbindung genauso wie für eine Videoverbindung, eine Instant Messaging Session, eine Kollaborationsanwendung usw. gilt. Diese von vornherein in den IMS-Standard eingebaute Multimedia-Fähigkeit macht einen großen Teil der Flexibilität von IMS aus. 5.3 Anruf SIP-PSTN Im Prinzip läuft ein Session-Aufbau von einem SIP-Teilnehmer zu einem PSTN-Teilnehmer ähnlich zu dem in Kapitel 5.2 beschriebenen Verfahren ab. Daher sollen hier nur einige wichtige Unterschiede herausgearbeitet werden. Wenn der originierende S-CSCF die TEL URL per Enum-Anfrage an den DNS/Enum-Server sendet, wird er keine sinnvolle Auflösung erhalten, so daß eine PSTN- (oder PLMN-) Übergabe getriggert wird. Über eine BGCF (Break-out Gateway Control Function) wird ein Media Gateway Controller selektiert (beispielsweise könnte über eine Analyse der B-Nummer einer von mehreren regional verteilten MGCs ausgewählt werden), der für die Übergabe der Session an das leitungsvermittelte Netz zuständig ist. Der MGC selektiert ein MGW, das die entsprechende Funktion auf der Nutzdatenebene erfüllt. Die Codec-Verhandlung findet nun zwischen dem IMS-Terminal und dem MGW statt. Danach wird über eine ausgehende ISUP-Signalisierung der Anruf zum B-Teilnehmer im leitungsvermittelten Netz aufgebaut. Bemerkung: Unter bestimmten Voraussetzungen gibt es auch die Möglichkeit, daß der MGC sofort nach Erhalt der INVITE-Anfrage ein ISUP IAM in das leitungsvermittelte Netz sendet. 6 Zusammenfassung und Ausblick Der neue Multimedia-Standard IMS schafft in idealer Weise eine Verbindung zwischen Festnetz und Mobilfunk, zwischen Telekommunikation und Internet, zwischen VoIP-Sprachverbindung und weiteren Kommunikationsarten. Alles, was eine IP-Adresse besitzt und einen SIP/RTP-Client aufnehmen kann, kann über IMS miteinander kommunizieren. Die inhärente Flexibilität des SIP läßt beliebige Arten von Multimedia-Sessions zu. Solange solche Multimedia-Elemente in SDP beschreibbar sind, können sie flexibel zwischen den Endstellen verhandelt, aufgebaut und später wieder gewechselt oder abgebaut werden. IMS wurde zunächst als Mobilfunkstandard erarbeitet, ist aber durch ETSI ebenfalls zum zentralen Baustein der Festnetz-NGN-Standardisierung gemacht worden. Durch seine „mobile“ Abstammung bringt der IMS-Standard quasi automatisch eine Lösung für viele früher von ETSI als problematisch angesehene Anwendungsfälle mit, z.B. für nomadische Anwender. Die Zusammenarbeit der Standardisierungsgremien für Mobilfunk und Festnetz wird zu weiteren interessanten Entwicklungen führen, wie z.B. der des VCC-Standards (Voice Call Continuity, die Möglichkeit der unterbrechungsfreien Gesprächsübergabe zwischen Mobilfunk und WLAN-Netz). Durch die Entscheidung von ETSI, sich 3GPP anzuschließen, gibt es erstmals eine standardisierte Technologie, auf deren Basis Fixed Mobile Convergence ohne proprietäre Lösungen errichtet werden kann. Und möglicherweise werden sogar Festnetzanbieter IMS früher kommerziell einsetzen als Mobilfunkanbieter. Denn nach wie vor ist der Sprachverkehr ein zentraler Dienst in allen Netzen; VoIP über IMS kann im Mobilfunk erst mit der Einführung von 3GPP-R7–konformer Infrastruktur zuverlässig unterstützt werden (alle anderen heutigen Versuche basieren auf „Best Effort“ – ohne zugesicherte Bandbreite und Verbindungsqualität). Da man im Festnetz IMS-basiertes VoIP bereits heute einführen kann (und einige Anbieter das auch schon getan

haben), bietet sich für Festnetzanbieter die einmalige Chance, sich trotz des „mobilen“ Stammbaums von IMS beim Next-Generation-Network-Standard schon heute Erfahrung beim kommerziellen Einsatz zu erarbeiten. In der Zwischenzeit haben Mobilfunkanbieter die Möglichkeit, entweder IMS-Angebote mit „Best Effort Voice“ zu schnüren, die in nicht zu sehr beanspruchten Funkzellen immer noch hinreichende Qualität bieten sollten. Sie können IMS-Dienste wie Presence, Instant Messaging, Gaming usw. anbieten oder können von der Möglichkeit Gebrauch machen, Nicht-Echtzeitdienste über IMS mit einer parallelen leitungsvermittelten Sprachverbindung zu koppeln, beides koordiniert durch das Endgerät (sog. Combinational Services). Unabhängig davon, wie der hier skizzierte Wettlauf ausgeht, oder ob er überhaupt in dieser Form stattfindet: In einigen Jahren, wenn das konvergente Multimedia-System IMS die dominierende Netztechnik ist, an die eine Vielzahl von Zugangsnetzen angeschlossen ist (xDSL, UMTS, WLAN, Wimax usw.), wird die Unterscheidung zwischen Festnetz- und Mobilfunkanbieter letztendlich ihre Bedeutung verlieren. 7 Bibliographie 7.1 IETF RFCs [1] = RFC 3261, J. Rosenberg, H. Schulzrinne, G. Camarillo, et.al. : SIP: Session Initiation Protocol [2] = RFC 3588, P. Calhoun, J. Loughney, E. Guttman, et al.: DIAMETER Base Protocol [3] = RFC 4566, M.Handley, V. Jacobson, C.Perkins: SDP: Session Description Protocol 7.2 3GPP Spezifikationen [4] = 3GPP TS 22.228: Service requirements for the IP multimedia core network subsystem [5] = 3GPP TS 23.228: IP Multimedia Subsystem (IMS); Stage 2 [6] = 3GPP TS 24.228: Signalling flows for the IP multimedia call control based on SIP and SDP [7] = 3GPP TS 24.229: IP Multimedia Call Control based on SIP and SDP; Stage 3 [8] = 3GPP TS 26.236: Packet switched conversational multimedia applications; Transport protocols [9] = 3GPP TS 29.228: IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and message contents [10] = 3GPP TS 29.229: Cx and Dx interfaces based on the Diameter protocol; Protocol details [11] = 3GPP TS 32.299: Diameter charging applications 7.3 Andere Quellen [12] = Gonzalo Camarillo, Miguel A. Garcia-Martin: The 3G IP Multimedia Subsystem, John Wiley and sons, Ltd [13] = Professor Thomas Magedanz, Fraunhofer FOKUS, im EURESCOM Mess@ge 01/2006 (März) [14] = Ingemar Lindblad and Johny Nyman: Ericsson’s IMS solution for enterprise—The vehicle for collaboration, Ericsson Review, no. 02, 2005

8 Glossar

3GPP 3rd Generation Partnership Project: Standardisierungskörperschaft für GSM, UMTS, IMS

AS Application Server: Anwendungsserver, die vom IMS-Vermittlungsnetz über die offene ISC-Schnittstelle in den Session-Ablauf miteinbezogen werden und so einfache oder Mehrwertdienste ermöglichen; vergleichbar mit IN-Servern (SCP) in heutigen Systemen; definiert in 3GPP TS 23.002

ABG Access Border Gateway: Session Border Gateway zwischen dem IMS-Vermittlungsnetz und einem Zugangsnetz

BGCF Border Gateway Control Function: wird in Verkehrsfällen gebraucht, bei denen eine SIP-Session im leitungsgebundenen Netz terminiert; BGCF sucht nach bestimmten Kriterien die richtige MGCF aus

CDR Charging Data Record CSCF Call Session Control Function: zentraler Multimedia-

Softswitch im IMS; verwendet SIP als Signalisierungsprotokoll (Ausnahme: DIAMETER zum HSS); kommt in verschiedenen logischen Ausprägungen vor (P-, I-, S-CSCF), die je nach Netzauslegung getrennt oder zusammen auf einem physischen CSCF-Knoten untergebracht werden

DHCP Dynamic Host Configuration Protocol: ermöglicht, Computern im lokalen Netz dynamisch ihre IP-Adressen zuzuweisen

DNS Domain Name System: Netz von Datenbanken, die Internet-Domänen-Namen wie Ericsson.com in IP-Adressen übersetzen; definiert in IETF STD 13, RFC 1034, und RFC 1035

Enum Protokoll, das aus der Arbeit der IETF Telephone Number Mapping Working Group resultiert; definiert in IETF RFC 2916; beschreibt eine DNS-basierte Architektur und Protokolle zur Abbildung einer Telefonnummer auf einen URI

ETSI European Telecommunication Standard Institute: Standardisierungskörperschaft für Festnetz- und Übertragungstechniken

ETSI-TISPAN

ETSI – Telecommunication and Internet Convergence in Signaling and Protocols for Advanced Networking: ETSI Arbeitsgruppe, die für die Standardisierung der Next Generation Networks zuständig ist; arbeitet eng mit 3GPP zusammen um sicherzustellen, daß mobile und feste Ausprägungen des IMS-Standards dort kompatibel bleiben, wo starke Überschneidungen gegeben sind

HSS Home Subscriber Server (HSS): Teilnehmerdatenbank im IMS; definiert in 3GPP TS 23.002

HTTP Hypertext Transfer Protocol: Protokoll auf

Applikationsebene für verteilte, kollaborative Hypermedien-Informationssysteme; definiert in IETF RFC 2616

IETF Internet Engineering Task Force: technisches Internet-Gremium; zuständig für die Entwicklung des Internet und die seine Protokolle betreffende Standardisierung

IP Internet Protocol: universelles Protokoll zum Austausch von Datenpaketen zwischen zwei Knoten

MGCF Media Gateway Control Function (auch MGC = Media Gateway Controller): zuständig für Auswahl und Steuerung entsprechender Media-Gateway-Einheiten, um eine Session zwischen IMS-Netz und leitungsvermitteltem Netz umzusetzen

MGCP Multimedia Gateway Control Protocol: wird vom MGC verwendet, um das MGW zu steuern

MGW Media Gateway: stellt im IMS die Schnittstelle zwischen der Medienebene von leitungsvermittelten Netzen (PSTN, PLMN) und dem IMS Netz dar

MRF Media Resource Function: ermöglicht die manipulation des Bitstroms; wird durch das CS-MS geliefert

NBG Network Border Gateway: Ein Session Border Gateway zwischen dem IMS-Vermittlungsnetz und einem anderen IP-basierten Vermittlungsnetz

NGN Next Generation Network: von ETSI verwendeter Begriff, um die Netze der nächsten Generation zu bezeichnen, die sich in vielen Merkmalen deutlich von heutigen Festnetzen abheben; aufgrund der Eigenschaften des IMS-Standards sind dies zum Beispiel IP-Netz-basiert, Softswitch-Architektur, Multimedia-Fähigkeit, QoS-Steuerung, Unterstützung für nomadische Anwendungen, Basis für Fixed Mobile Convergence, offene Schnittstellen zu Teilnehmerdatenbank und Anwendungsservern

OMA Open Mobile Alliance: Industriegremium, das es sich zur Aufgabe gemacht hat, die universelle Einführung von mobilen Anwendungen durch eine verbesserte Spezifikation zu erleichtern; wo 3GPP den Standard und die Protokolle vorgibt, kann OMA noch einen Schritt weitergehen und vorschlagen, wie der Standard auf Applikationsebene konkret ausgefüllt wird

PLMN Public Land Mobile Network: GSM- oder UMTS-Mobilfunknetz

PSTN Public Service Telephone Network: leitungsvermitteltes Festnetz

SBC Session Border Controller SDP Session Description Protocol: SDP beschreibt Multimedia-

Sessions inhaltlich, bezogen auf die Art der Medienströme, verwendete Codecs, Ports usw.; wird verwendet, um die gewünschte bzw. unterstützte Multimedia-Session zwischen Gegenstellen zu beschreiben und abzugleichen; SIP

verwendet SDP beim Aufbau oder Modifizieren einer Session; definiert in IETF RFC 2327

SIP Session Initiation Protocol: Signalisierungsprotokoll zum Aufbau, Modifizieren und Abbau von Sessions über IP-basierte Netze mit einem oder mehreren Teilnehmern; definiert in IETF RFC 3261

TDM Time Division Multiplexing: Übertragungsstandard in leitungsvermittelten Netzen

URI Uniform Resource Identifier: Zeichenfolge, die zur Identifizierung einer abstrakten oder physischen Ressource in Computernetzen dient; werden zur Bezeichnung von Ressourcen wie Webseiten, Dateien, Webservices, E-Mail-Empfängern in Computernetzen eingesetzt

URL Uniform Resource Locator: Unterart von Uniform Resource Identifiern (URIs); identifizieren eine Ressource über ihren primären Zugriffsmechanismus (häufig http oder ftp) und den Ort der Ressource in Computernetzen