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

Größe: px
Ab Seite anzeigen:

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

Transkript

1 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.

2 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, 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 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.

3 UA UA Bild 1: IMS Netzarchitektur im Überblick 2.2 IMS Netzknoten 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 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) 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

4 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 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 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 den Nutzer tatsächlich verwaltet. Zu diesem Zweck führt der I-CSCF eine Abfrage des HSS durch, welcher 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 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 ist daher die wichtigste aller drei CSCF- Ausprägungen. Nach der Allokation eines zu einem Benutzer lädt der 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 gehörig an (für eventuelle zukünftige Abfragen durch das I-CSCF). Zwei weitere wichtige Funktionen zeigen die zentrale Rolle des s 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 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 im E.164-Fall zunächst eine B-Nummern-Normalisierung durchführen, um eine Eindeutigkeit der E.164-Nummern zu gewährleisten 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 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

5 Daten anderen Netzelementen zur Verfügung (I-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 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) 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) 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 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.

6 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 oder sowie einer optionalen Parameterliste. Dabei ist der 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: sip: mainsipserver sip: sip: sip: 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: 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 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 SIP URI Als Public ID kann die schon aus Kapitel 3.1 bekannte SIP URI verwendet werden. Sie hat dann die aus -Adressen bekannte Struktur versehen mit dem Kennwort sip:: Beispiel: oder user=phone

7 Die zweite Adresse ist dabei ein Beispiel für die in Kapitel 3.1 genannte optionale Parameterliste ;user=phone TEL URL Als Public ID kann auch die schon aus Kapitel 3.2 bekannte TEL URL verwendet werden. Beispiel: tel: 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 Ü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

8 NOTIFY MESSAGE OPTIONS PRACK PUBLISH REGISTER REFER SUBSCRIBE UPDATE Session Benachrichtigung über eine Änderung im Verfügbarkeitszustandes (Presence) eines Teilnehmers, dessen Presence man abonniert hat Anforderung zur Direktübertragung einer Instant Message Anfrage an einen Server, seine Fähigkeiten (Options) darzulegen Bestätigt eine vorläufige Antwort (PRovisional response ACKnowledgement) ein SIP UA gibt über die Publish-Anfrage seinen Verfügbarkeitszustand (Presence) bekannt Anforderung, einen User Agent erstmalig oder wiederholt beim System zu registrieren Anforderung an einen Server, einen neuen oder modifizierten Request zu senden (zur Umleitung von SIP-Signalen verwendet) Anforderung, über den Verfügbarkeitszustand eines Teilnehmers (Presence) informiert zu werden (subscribe = abonnieren) 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 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/ Ringing oder SIP/ 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 vorläufige Antworten (wie SIP/ Ringing im Beispiel oben) erfolgreiche Antworten, z.b. SIP/ OK, die Bestätigung Statuscodes für Umleitungen (Re-Direction) Client-Fehlerfälle Server-Fehlerfälle globaler Fehlerfall

9 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 IN IP s=sdp Seminar i=discussion of the sdp c=in IP /127 t= m=audio RTP/AVP 0 a=sendrecv m=video 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.

10 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 Ü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. Conversational Multimedia Application Audio Video Text RTCP Payload formats RTP UDP IP Bild 2: Protokollaufbau für Multimedia-Echtzeitdienste 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 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

11 - 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 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 ) 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 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 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 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 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. Hier gibt es zwei Möglichkeiten, zum einen, daß dem Benutzer schon ein zugewiesen wurde, oder zum anderen, daß noch keiner für diesen Benutzer allokiert wurde. Welche der beiden Möglichkeiten zutrifft, erfährt der

12 I-CSCF über eine Abfrage des HSS (5). Im ersten Fall wird die Anfrage mit der Adresse des zugewiesenen beantwortet, im zweiten mit einer Liste von Kriterien, die der I-CSCF bei der Auswahl eines geeigneten s berücksichtigen muß. Im Bild 3 wird vom zweiten Fall ausgegangen (6). Der I-CSCF wählt dann einen entsprechenden aus und leitet daraufhin die REGISTER-Anfrage an den ausgewählten weiter (7). Besuchtes Netz Heimat-Netz DNS HSS (1)REGISTER P-CSCF (12)401 UNAUTH. (2) DNS query (3) home I-CSCF (4)REGISTER (11) 401 UNAUTH. (5) HSS query (6) req. cap s. I-CSCF I-CSCF (8) HSS query (9) sub.auth.data (7)REGISTER (10) 401 UNAUTH. UA 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 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/ 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 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/ 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:

13 - 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 herunterzuladen (wie im Fall der Erstregistrierung), sondern ergibt jetzt als Resultat die Adresse des bereits im ersten Schritt ausgewählten. - Die -Signalisierung zum HSS dient nicht wie beim ersten Mal zum Registrieren des s für diesen Benutzer, sondern zur erfolgreichen Registrierung des Benutzers selbst. Als HSS-Antwort werden nicht die Authentifizierungsdaten heruntergeladen, sondern alle Teilnehmerdaten, die der zur Handhabung dieses Teilnehmers braucht. - Die Rückantwort an den UA ist nicht negativ, sondern positiv (200 OK, erfolgreiche Authentifizierung vorausgesetzt). Besuchtes Netz Heimat-Netz DNS HSS P-CSCF (2) DNS query (3) home I-CSCF (5) HSS query (6) (8) HSS query (9) sub.data (1)REGISTER (12)200 OK (4)REGISTER (11) 200 OK I-CSCF I-CSCF UA (7)REGISTER (10) 200 OK Bild 4: Registrierung eines SIP User Agents, Teil Endbenutzerdaten im 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 mit eingeschlossen sein sollen, gängige Möglichkeiten sind entweder eine direkte P-CSCF-zu--Kommunikation oder die Beibehaltung der P-CSCF/I-CSCF/-Reihenfolge.

14 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 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 beschriebenen Vorgang kennt (1). In diesem Fall hatte der bei Abschluß der Registrierung vorgeschrieben, daß der direkt kontaktiert werden soll, unter Auslassung eines I-CSCF im Heimatnetz, siehe auch Kapitel (2). Gastnetz A Heimnetz A Heimnetz B Gastnetz B P-CSCF (1)INVITE (16)SESSION PROGRESS (2a)INVITE (2b)INVITE (2)INVITE AS (15)SESSION PROGRESS (3)DNS query (4)term.I-CSCF DNS (5)INVITE (14)SESSION PROGRESS I-CSCF (13)SESSION PROGRESS (6)HSS query (7) (8)INVITE HSS AS (8a)INVITE (8b)INVITE (9)INVITE (12)SESSION PROGRESS P-CSCF (11)SESSION PROGRESS (10)INVITE UA (A) UA (B) Bild 5: SIP-zu-SIP-Session-Aufbau, Teil1

15 5.2.2 Aufgaben des originierenden Falls der 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, 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 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. Dieses geschieht durch eine HSS-Abfrage (6), die mit der Adresse des terminierenden beantwortet wird (7). Die letzte Aufgabe des terminierenden I-CSCF ist dann die Weiterleitung der INVITE-Anfrage an den terminierenden (8) Aufgaben der terminierenden und P-CSCF Die Anfrage zum Session-Aufbau ist nun im des IMS-Teilnehmers B angekommen. Der 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 (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 nach der Registrierung die gegenwärtige Adresse des Benutzers sowie seines gültigen P-CSCFs enthält, kann der 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) 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.

16 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 DNS HSS (2) UPDATE (3) UPDATE I-CSCF (4) UPDATE P-CSCF P-CSCF (9)200 OK (8)200 OK (7)200 OK (5)UPDATE (1)UPDATE (10)200 OK (6)200 OK UA UA 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.

17 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 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

18 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 : Service requirements for the IP multimedia core network subsystem [5] = 3GPP TS : IP Multimedia Subsystem (IMS); Stage 2 [6] = 3GPP TS : Signalling flows for the IP multimedia call control based on SIP and SDP [7] = 3GPP TS : IP Multimedia Call Control based on SIP and SDP; Stage 3 [8] = 3GPP TS : Packet switched conversational multimedia applications; Transport protocols [9] = 3GPP TS : IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and message contents [10] = 3GPP TS : Cx and Dx interfaces based on the Diameter protocol; Protocol details [11] = 3GPP TS : 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 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

19 8 Glossar 3GPP AS ABG BGCF CDR CSCF DHCP DNS Enum ETSI ETSI- TISPAN HSS HTTP 3rd Generation Partnership Project: Standardisierungskörperschaft für GSM, UMTS, IMS 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 Access Border Gateway: Session Border Gateway zwischen dem IMS-Vermittlungsnetz und einem Zugangsnetz 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 Charging Data Record 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-, ), die je nach Netzauslegung getrennt oder zusammen auf einem physischen CSCF-Knoten untergebracht werden Dynamic Host Configuration Protocol: ermöglicht, Computern im lokalen Netz dynamisch ihre IP-Adressen zuzuweisen 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 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 European Telecommunication Standard Institute: Standardisierungskörperschaft für Festnetz- und Übertragungstechniken 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 Home Subscriber Server (HSS): Teilnehmerdatenbank im IMS; definiert in 3GPP TS Hypertext Transfer Protocol: Protokoll auf

20 IETF IP MGCF MGCP MGW MRF NBG NGN OMA PLMN PSTN SBC SDP Applikationsebene für verteilte, kollaborative Hypermedien- Informationssysteme; definiert in IETF RFC 2616 Internet Engineering Task Force: technisches Internet- Gremium; zuständig für die Entwicklung des Internet und die seine Protokolle betreffende Standardisierung Internet Protocol: universelles Protokoll zum Austausch von Datenpaketen zwischen zwei Knoten 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 Multimedia Gateway Control Protocol: wird vom MGC verwendet, um das MGW zu steuern Media Gateway: stellt im IMS die Schnittstelle zwischen der Medienebene von leitungsvermittelten Netzen (PSTN, PLMN) und dem IMS Netz dar Media Resource Function: ermöglicht die manipulation des Bitstroms; wird durch das CS-MS geliefert Network Border Gateway: Ein Session Border Gateway zwischen dem IMS-Vermittlungsnetz und einem anderen IPbasierten Vermittlungsnetz 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 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 Public Land Mobile Network: GSM- oder UMTS- Mobilfunknetz Public Service Telephone Network: leitungsvermitteltes Festnetz Session Border Controller 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

Digitale Sprache und Video im Internet

Digitale Sprache und Video im Internet Digitale Sprache und Video im Internet Kapitel 6.4 SIP 1 SIP (1) SIP (Session Initiation Protocol), dient als reines Steuerungsprotokoll (RFC 3261-3265) für MM-Kommunikation Weiterentwicklung des MBONE-SIP.

Mehr

Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik. Hauptseminar. VoIP in Mobilfunknetzen auf Basis von IMS

Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik. Hauptseminar. VoIP in Mobilfunknetzen auf Basis von IMS Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Hauptseminar vorgelegt von: Hamad Kountar eingereicht am: 31. 06. 2008 geboren am: Studiengang: Elektrotechnik und Informationstechnik

Mehr

Proseminar IP-Telefonie. Timo Uhlmann. Einleitung 1 2 3 4 5

Proseminar IP-Telefonie. Timo Uhlmann. Einleitung 1 2 3 4 5 Proseminar IP-Telefonie Timo Uhlmann Einleitung 1 2 3 4 5 Inhalt 1. Motivation 2. Protokolle H.323 3. Kosten/Angebote 4. Fazit Einleitung 1 2 3 4 5 2/24 Motivation Telefonieren kostet Geld (noch) zeitabhängig

Mehr

14. Fachtagung Mobilkommunikation Osnabrück

14. Fachtagung Mobilkommunikation Osnabrück SOA-basierte Peer-to-Peer-Mehrwertdienstebereitstellung 14. Fachtagung Mobilkommunikation Osnabrück 13. - 14. Mai 2009 Dipl.-Ing. Armin Lehmann, Prof. Dr.-Ing. Ulrich Trick Fachhochschule Frankfurt am

Mehr

13. Mobilfunk-Fachtagung Osnabrück

13. Mobilfunk-Fachtagung Osnabrück Neue Möglichkeiten der Dienstebereitstellung durch -to--kommunikation 13. Mobilfunk-Fachtagung Osnabrück 28. - 29. Mai 2008 Dipl.-Ing. Armin Lehmann (lehmann@e-technik.org) M. Sc. Dipl.-Inf. Thomas Eichelmann

Mehr

Handbuch Notruf. Notrufe über Voice over IP: Grundlagen und Praxis. www.handbuch-notruf.at. Karl Heinz Wolf nic.at GmbH. Ausschnitt aus dem

Handbuch Notruf. Notrufe über Voice over IP: Grundlagen und Praxis. www.handbuch-notruf.at. Karl Heinz Wolf nic.at GmbH. Ausschnitt aus dem Karl Heinz Wolf nic.at GmbH Ausschnitt aus dem Handbuch Notruf Notrufe über Voice over IP: Grundlagen und Praxis www.handbuch-notruf.at Handbuch Notruf 3 4 IETF-Notrufarchitektur Bei der IETF wird derzeit

Mehr

11. Mobilfunktagung Osnabrück

11. Mobilfunktagung Osnabrück -basierte NGN-Architekturen und das IMS 11. Mobilfunktagung Osnabrück 17. und 18. Mai 2006 Dipl.-Ing. (FH) Frank Weber (weber@e-technik.org) Prof. Dr.-Ing. Ulrich Trick (trick@e-technik.org) Fachhochschule

Mehr

Vorwort zur fünften Auflage

Vorwort zur fünften Auflage Inhalt Vorwort zur fünften Auflage XIII 1 Anforderungen an die Telekommunikationsinfrastruktur der Zukunft 1 1.1 Telekommunikationsinfrastruktur 3 1.2 Kommunikationsdienste und Nutzerverhalten 6 1.3 Applikationen

Mehr

C.45 C.46 C.48. 3.7 Registrierung der Teilnehmer. 3.7 Registrierung der Teilnehmer (2) 3.7 Registrierung der Teilnehmer (3)

C.45 C.46 C.48. 3.7 Registrierung der Teilnehmer. 3.7 Registrierung der Teilnehmer (2) 3.7 Registrierung der Teilnehmer (3) 3.7 Registrierung der Teilnehmer 3.7 Registrierung der Teilnehmer (2) Registrarknoten z.b. von einer administrativen Domäne verwaltet initiale SIP REGISTER-Transaktion zum Registrar der Domäne alice@a.com

Mehr

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol SIP - Session Initiation Protocol PPS VoIP 5. Oktober 2009 Lernziele Sie kennen die Position und Aufgabe von SIP im Protokollmodell Sie kennen die wesentlichen Elemente eines SIP Netzes Sie wissen wie

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

dtms ENUM Gateway Michael Volpert Abtlg. Recht / Regulierung dtms AG

dtms ENUM Gateway Michael Volpert Abtlg. Recht / Regulierung dtms AG dtms ENUM Gateway Michael Volpert Abtlg. Recht / Regulierung dtms AG Agenda 1. Kurzvorstellung dtms AG -> SCP-Carrier 2. Projektziele 3. dtms ENUM-Gateway 4. Rahmen / Lookup 5. Bewertung 6. Weitere Planung

Mehr

Die Next Generation Networks im Hochschullabor

Die Next Generation Networks im Hochschullabor Die Next Generation Networks im Hochschullabor Prof. Dr. Ulrich Trick, am Main, Fachbereich Informatik und Ingenieurwissenschaften,, Kleiststr. 3, 60318 Frankfurt, Tel. 06196/641127, E-Mail: trick@e-technik.org,

Mehr

Voice over IP. Sprache und Daten in einem gemeinsamen Netz. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Voice over IP. Sprache und Daten in einem gemeinsamen Netz. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Voice over IP Sprache und Daten in einem gemeinsamen Netz Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Normen Ablauf und Einzelheiten Verbindungsaufbau und Verbindungsverwaltung

Mehr

VoIP. Gliederung. 1. Einführung. 3.2Anforderungen 3.3Stand Dinge. 3.3Wie geht es Dinge weiter?

VoIP. Gliederung. 1. Einführung. 3.2Anforderungen 3.3Stand Dinge. 3.3Wie geht es Dinge weiter? Sicherheit Ruhr-Universität Voice over IP Thomas WS Seminar (VoIP 2004/2005 VoIP) Eisenbarth ITS Bochum 1. Einführung 1.1 1.2 1.3 Was Bisherige Die Zukunft ist VoIP? Telefonie Gliederung 10.02.2005 - Folie

Mehr

SIRTCP/IP und Telekommunikations netze

SIRTCP/IP und Telekommunikations netze SIRTCP/IP und Telekommunikations netze Next Generation Networks und VolP - konkret von Ulrich Trick und Frank Weber 2., erweiterte und aktualisierte Auflage Oldenbourg Verlag München Wien Inhalt Inhalt

Mehr

SIRTCP/IP und Telekommunikations netze

SIRTCP/IP und Telekommunikations netze SIRTCP/IP und Telekommunikations netze Anforderungen - Protokolle -Architekturen Von Ulrich Trick und Frank Weber Oldenbourg Verlag München Wien Inhalt Vorwort IX 1 Anforderungen an die Telekommunikationsinfrastruktur

Mehr

Erweiterung der Autokonfigurationsmethode für Rich Communications Suite enhanced (RCS-e) durch die COCUS AG

Erweiterung der Autokonfigurationsmethode für Rich Communications Suite enhanced (RCS-e) durch die COCUS AG Erweiterung der Autokonfigurationsmethode für Rich Communications Suite enhanced (RCS-e) durch die COCUS AG 01.06.2016 Autoren: Sascha Hellermann (Geschäftsführer COCUS NEXT GmbH) Simon Probst (Solution

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

Buchner Roland, Günther Markus, Fischer Oliver

Buchner Roland, Günther Markus, Fischer Oliver Buchner Roland, Günther Markus, Fischer Oliver Telefonieren über das Datennetz Erster Hype schon in den 90ern seit CeBIT 2004 wieder im Gespräch Erobert Telekommunikationsmarkt Alle großen Telekom Anbieter

Mehr

SIP-ST Anlagenanschluss. Funktionsbeschreibung. 2016, ENTEGA Medianet GmbH 1. KD-820-321-400 SIP ST Anlageanschluss

SIP-ST Anlagenanschluss. Funktionsbeschreibung. 2016, ENTEGA Medianet GmbH 1. KD-820-321-400 SIP ST Anlageanschluss Funktionsbeschreibung 2016, ENTEGA Medianet GmbH 1 Inhaltsverzeichnis Einleitung... 3 Voice-over-IP (VoIP)... 3 IP-TK-Anlagenanschluss der ENTEGA Medianet... 3 Netzübersicht... 4 Netzübersicht SIP-TK-Anlagenanschluss...

Mehr

NGN Eine Übersicht. VDE/ITG FG 5.2.3 Harald Orlamünder

NGN Eine Übersicht. VDE/ITG FG 5.2.3 Harald Orlamünder NGN Eine Übersicht VDE/ITG FG 5.2.3 Harald Orlamünder Inhalt > Definition von NGN, Abgrenzung > Architektur von NGNs > Einführung von NGNs > Was bleibt noch zu tun? NGN eine Übersicht 2 Definition [Y.2001]

Mehr

Application Server und Service Provisioning

Application Server und Service Provisioning Application Server und Service Provisioning ITG-Fachtagung Zukunft der Netze Universität Bremen 17. November 2006 Prof. Dr.-Ing. Ulrich Trick, Dipl.-Ing. (FH) Sven Burdys Fachhochschule Frankfurt am Main,

Mehr

7. SICTA Kolloquium NGN Standardisierung

7. SICTA Kolloquium NGN Standardisierung 7. SICTA Kolloquium NGN Standardisierung NGN in der Schweiz Disclaimer Die in dieser Präsentation gemachten Aussagen decken sich nicht notwendigerweise mit den Ansichten der Siemens AG und der Siemens

Mehr

Streaming Protokolle Jonas Hartmann

Streaming Protokolle Jonas Hartmann Streaming Protokolle Jonas Hartmann 1 Streaming Protokolle Inhaltsverzeichnis 1. Definition / Anwendungsfälle 2. Offizielle RFC Streaming Protokolle 3. Ein wichtiges proprietäres Protokoll 4. Konkreter

Mehr

(51) Int Cl.: H04L 12/56 (2006.01) H04L 29/06 (2006.01) H04L 29/08 (2006.01)

(51) Int Cl.: H04L 12/56 (2006.01) H04L 29/06 (2006.01) H04L 29/08 (2006.01) (19) (12) EUROPÄISCHE PATENTANMELDUNG (11) EP 1 936 877 A1 (43) Veröffentlichungstag: 2.06.2008 Patentblatt 2008/26 (21) Anmeldenummer: 0602620.8 (1) Int Cl.: H04L 12/6 (2006.01) H04L 29/06 (2006.01) H04L

Mehr

Lawful Interception (LI) für IP basierte Dienste. Standardisierung bei ETSI

Lawful Interception (LI) für IP basierte Dienste. Standardisierung bei ETSI Lawful Interception (LI) für IP basierte Dienste Standardisierung bei ETSI Historisches Leitungsvermittelte Netze (PSTN, ISDN und GSM) Überwachungsverordnung schreibt Implementierung von ES 201 671 in

Mehr

Modul 12: 12.1 Vertiefung Paket- u. Leitungsvermittlung 12.2 Voice over IP, Next Generation Networks

Modul 12: 12.1 Vertiefung Paket- u. Leitungsvermittlung 12.2 Voice over IP, Next Generation Networks Modul 12: 12.1 Vertiefung Paket- u. Leitungsvermittlung 12.2 Voice over IP, Next Generation Networks 17.06.2014 16:57:15 Folie 1 12.1 Vertiefung Paketund Leitungsvermittlung 17.06.2014 16:57:16 Folie 2

Mehr

Geleitwort...V. Vorwort...VII

Geleitwort...V. Vorwort...VII Mehr Informationen zum Titel Inhaltsverzeichnis IX Inhaltsverzeichnis Geleitwort.............................................................V Vorwort..............................................................VII

Mehr

Mehr als Voice over IP Integrierte Sprach- und SIP. =====!" ==Systems= Wolfgang Mandok T-Systems Nova, Technologiezentrum

Mehr als Voice over IP Integrierte Sprach- und SIP. =====! ==Systems= Wolfgang Mandok T-Systems Nova, Technologiezentrum Mehr als Voice over IP Integrierte Sprach- und IP-Kommunikationslösungen basierend auf SIP Wolfgang Mandok T-Systems Nova, Technologiezentrum Mehr als Voice over IP Übersicht 1. Einleitung 2. SIP Architektur

Mehr

Neue Dienste und Anwendungen für private, intelligente Kommunikationsnetzwerke

Neue Dienste und Anwendungen für private, intelligente Kommunikationsnetzwerke . Neue Dienste und Anwendungen für private, intelligente Kommunikationsnetzwerke (Next Generation Service Capabilities for private intelligent Networks) Übersicht des Vortrags Kommunikationsnetzwerk der

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Architekturen für IP-basierte Funkzugangsnetze

Architekturen für IP-basierte Funkzugangsnetze Radio Network Concepts Architekturen für IP-basierte Funkzugangsnetze Michael Schopp,, Helmut Becker Radio Network Concepts Information and Communication Mobile Siemens AG ITG-Workshop IP in Telekommunikationsnetzen

Mehr

Next Generation Networks

Next Generation Networks Gerd Siegmund Next Generation Networks IP-basierte Telekommunikation Hüthig Verlag Heidelberg Inhaltsverzeichnis 1 Einführung.. 1 1.1 Netze im Wandel 1 1.1.1 Übersicht 3 1.1.2 Ein Zielnetz oder zunehmende

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Mobility Support by HIP

Mobility Support by HIP Mobile Systems Seminar Mobility Support by HIP Universität Zürich Institut für Informatik Professor Dr. Burkhard Stiller Betreuer Peter Racz 8 Mai 2008 Svetlana Gerster 01-728-880 1 Gliederung OSI und

Mehr

SIP-PBX Anlagenanschluss. Funktionsbeschreibung. 2016, ENTEGA Medianet GmbH 1. KD-820-311-400 SIP PBX Anlageanschluss

SIP-PBX Anlagenanschluss. Funktionsbeschreibung. 2016, ENTEGA Medianet GmbH 1. KD-820-311-400 SIP PBX Anlageanschluss Funktionsbeschreibung 2016, ENTEGA Medianet GmbH 1 Inhaltsverzeichnis Einleitung... 3 Voice-over-IP (VoIP)... 3 IP-TK-Anlagenanschluss der ENTEGA Medianet... 3 Netzübersicht... 4 Netzübersicht SIP-TK-Anlagenanschluss...

Mehr

EINRICHTUNG EINES MICROSOFT LYNC TM SERVERS 2010 MIT IPfonie extended link. IN VERBINDUNG MIT DEM QSC SIP-TRUNK IPfonie extended link INHALT

EINRICHTUNG EINES MICROSOFT LYNC TM SERVERS 2010 MIT IPfonie extended link. IN VERBINDUNG MIT DEM QSC SIP-TRUNK IPfonie extended link INHALT EINRICHTUNG EINES MICROSOFT LYNC TM SERVERS 2010 IN VERBINDUNG MIT DEM QSC SIP-TRUNK IPfonie extended link INHALT 1 Voraussetzungen 3 2 Auflistung der abschließenden Konfigurationsarbeiten 4 3 Konfiguration

Mehr

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen 9. Februar 2008 Vortrag für den PC-Treff Böblingen Agenda 1 Einleitung Netzwerkeinstellungen 2 Feste Zuordnung Lease 3 4 Einleitung Einleitung Netzwerkeinstellungen DHCP, das Dynamic Host Configuration

Mehr

EP 1 742 445 A1 (19) (11) EP 1 742 445 A1 (12) EUROPÄISCHE PATENTANMELDUNG. (43) Veröffentlichungstag: 10.01.2007 Patentblatt 2007/02

EP 1 742 445 A1 (19) (11) EP 1 742 445 A1 (12) EUROPÄISCHE PATENTANMELDUNG. (43) Veröffentlichungstag: 10.01.2007 Patentblatt 2007/02 (19) (12) EUROPÄISCHE PATENTANMELDUNG (11) EP 1 742 445 A1 (43) Veröffentlichungstag: 10.01.2007 Patentblatt 2007/02 (51) Int Cl.: H04L 29/12 (2006.01) (21) Anmeldenummer: 05014694.3 (22) Anmeldetag: 06.07.2005

Mehr

Aktuelle Möglichkeiten Informationen auszutauschen

Aktuelle Möglichkeiten Informationen auszutauschen Moderne Kommunikation Aktuelle Möglichkeiten Informationen auszutauschen Informationsmöglichkeiten Telefon analog/isdn Fax Telex, Teletext, Telebrief Videotext Telegramm SMS/MMS Internet (Email) Universal

Mehr

Man unterscheidet zwischen LAN (Local Area Network) und WAN (Wide Area Network), auch Internet genannt.

Man unterscheidet zwischen LAN (Local Area Network) und WAN (Wide Area Network), auch Internet genannt. Netzwerk Ein Netzwerk wird gebildet, wenn mehrere Geräte an einem Switch mit Netzwerkkabeln angeschlossen werden. Dabei können die einzelnen Geräte miteinander kommunizieren und über ein Netzwerkprotokoll

Mehr

Anlage zur Akkreditierungsurkunde D-PL-19015-01-00 nach DIN EN ISO/IEC 17025:2005

Anlage zur Akkreditierungsurkunde D-PL-19015-01-00 nach DIN EN ISO/IEC 17025:2005 Deutsche Akkreditierungsstelle GmbH Anlage zur Akkreditierungsurkunde D-PL-19015-01-00 nach DIN EN ISO/IEC 17025:2005 Gültigkeitsdauer: 15.12.2014 bis 14.12.2019 Ausstellungsdatum: 15.12.2014 Urkundeninhaber:

Mehr

Digicomp Microsoft Evolution Day 2015 1. Exchange UM Survival Guide Markus Hengstler Markus.Hengstler@umb.ch Partner:

Digicomp Microsoft Evolution Day 2015 1. Exchange UM Survival Guide Markus Hengstler Markus.Hengstler@umb.ch Partner: 1 Exchange UM Survival Guide Markus Hengstler Markus.Hengstler@umb.ch Partner: 2 Agenda Begrüssung Vorstellung Referent Content F&A Weiterführende Kurse 3 Vorstellung Referent Markus Hengstler MCT, MCM

Mehr

All-IP für den Mittelstand

All-IP für den Mittelstand All-IP für den Mittelstand DVPT Managementforum Digital Frankfurt, 04. November 2015 Telefonica Germany GmbH & Co OHG Telefónica in Deutschland Übersicht Größter Mobilfunkanbieter in Deutschland 39% Marktanteil

Mehr

Architekturen & Protokolle von Next Generation Networks (NGN)

Architekturen & Protokolle von Next Generation Networks (NGN) ITG-Fachausschuss 5.2 Kommunikationsnetze Systeme Workshop Zukunft der Netze 1. Oktober 2004, Kaiserslautern Architekturen & Protokolle von Next Generation Networks (NGN) (horlamuender@alcatel.de) Karl

Mehr

Seminar Mobile Systems. The Session Initiation Protocol in Mobile Environment

Seminar Mobile Systems. The Session Initiation Protocol in Mobile Environment Seminar Mobile Systems The Session Initiation Protocol in Mobile Environment 1 Lorenz Fischer, Ruben Meier Mobile Systems Seminar 13. Juni 2005 Übersicht Einführung Protokolle (SIP, SDP, RTP) Komponenten

Mehr

Inhaltsverzeichnis. Geleitwort

Inhaltsverzeichnis. Geleitwort Inhaltsverzeichnis Geleitwort Vorwort V VII 1 Grundlagen 1 1.1 Pakete im Internet 2 1.2 Erste Ansätze 3 1.2.1 H.323 von ITU-T 3 1.2.2 SIP von der IETF 4 1.2.3 Netze der nächsten Generation 4 1.3 VoIP oder

Mehr

SIP Konfiguration in ALERT

SIP Konfiguration in ALERT Micromedia International Technisches Dokument SIP Konfiguration in Alert Autor: Pierre Chevrier Seitenanzahl: 13 Firma: Micromedia International Datum: 16/10/2012 Update: Jens Eberle am 11.10.2012 Ref.

Mehr

Umstieg auf eine All-IP Lösung in Unternehmen

Umstieg auf eine All-IP Lösung in Unternehmen Umstieg auf eine All-IP Lösung in Unternehmen Hans-Jürgen Jobst November 2015 Managementforum Digital Agenda Umstellung auf ALL-IP Wie (S)IP die Kommunikationswelt weiter verändert Chancen und Herausforderungen

Mehr

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2)

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2) 14. URIs Uniform Resource Identifier 14-1 14. URIs Uniform Resource Identifier 14-2 Motivation Das WWW ist ein Hypermedia System. Es enthält: Resourcen (Multimedia Dokumente) Verweise (Links) zwischen

Mehr

Mobilität in IP (IPv4 und IPv6)

Mobilität in IP (IPv4 und IPv6) Mobilität in IP (IPv4 und IPv6) Prof. B. Plattner ETH Zürich IP Next Generation - Mobilität (1) Uebersicht Formen der Mobilitätsunterstützung 1 Echt mobile Benutzer (drahtlos erschlossene Laptops)» Handover

Mehr

CN.as COM - SIP Spezifikationen Notruf

CN.as COM - SIP Spezifikationen Notruf Dokument-Nr. Version Gültig ab Dokumenten- Status Verteilerstatus Arbeitsgruppe Anzahl Seiten 1.00 01.01.2016 öffentlich 000 10 PLaPB Technisches Planungshandbuch der ASFiNAG AUTOBAHNEN- UND SCHNELLSTRASSEN-FINANZIERUNGS-AKTIENGESELLSCHAFT

Mehr

Einführung. Internet vs. WWW

Einführung. Internet vs. WWW Einführung Bernhard Plattner 1-1 Internet vs. WWW "the Internet is the entirety of all computers which are interconnected (using various physical networking technologies) and employ the Internet protocol

Mehr

Begriffe. Proxy: Ein SIP Knoten, der sowohl als Client als auch als Server arbeitet. Hauptaufgabe ist das Routing von SIP Nachrichten.

Begriffe. Proxy: Ein SIP Knoten, der sowohl als Client als auch als Server arbeitet. Hauptaufgabe ist das Routing von SIP Nachrichten. Begriffe Client: Ein SIP Knoten, der SIP Requests verschickt und SIP Responses empfängt. Server: Ein SIP Knoten, der SIP Requests empfängt und SIP Responses sendet. User Agent (UA): Ein SIP Knoten, der

Mehr

Neue Möglichkeiten der Dienstebereitstellung durch Peer-to-Peer- Kommunikation

Neue Möglichkeiten der Dienstebereitstellung durch Peer-to-Peer- Kommunikation Neue Möglichkeiten der Dienstebereitstellung durch -to-- Kommunikation Armin Lehmann, Thomas Eichelmann, Ulrich Trick Fachhochschule Frankfurt/M. - University of Applied Sciences, Kleiststraße 3, 60318

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

Session Initiation Protocol

Session Initiation Protocol Session Initiation Protocol Funktionsweise, Einsatzszenarien, Vorteile und Defizite von Dipl. Inform. Petra Borowka Markus Schaub Seite i Inhaltsverzeichnis INHALTSVERZEICHNIS I 1 MOTIVATION 1-1 1.1 Die

Mehr

Geschichte und Anwendungsgebiete

Geschichte und Anwendungsgebiete VoIP Geschichte und Anwendungsgebiete Sehr geehrter Herr Schmid, liebe Mitschüler, wir möchte euch heute die Geschichte und die Anwendungsgebiete von Voice over IP etwas näher bringen. 1 Inhaltsangabe

Mehr

2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-D-VoD.fm, 2006-11-22 08.08] http://www-vs.informatik.uni-ulm.

2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-D-VoD.fm, 2006-11-22 08.08] http://www-vs.informatik.uni-ulm. D Video on Demand D.1 1 RTSP Real-Time Streaming Protocol (RTSP) IETF Standard definiert in RFC 2326 (1998) Zielsetzung Signalisierung und Kontrolle von multimedialen Datenströmen Aufbau, Abbruch von Sitzungen

Mehr

Voice over IP. Internet Telefonie

Voice over IP. Internet Telefonie VoIP SIP-Telefonie Voice over IP IP-Telefonie Internet Telefonie Agenda Was ist VoIP Geschichte Allgemeines H.323 SIP RTP / RTCP Skype Sicherheitsaspekte Quellenangaben VoIP? Voice over IP ist die Übertragung

Mehr

Michael Uhl, Vortrag VoIP Freitag, 16.06.2006

Michael Uhl, Vortrag VoIP Freitag, 16.06.2006 VoIP Voice over IP Dieser Vortrag stellt das Funktionsprinzip und einige einfache Anwendungen für VoIP vor. mu21.de Letzter Vortrag: GSM UMTS B3G ####################################################################

Mehr

Zukunft der Netze 6. Fachtagung der ITG-FA 5.2. Interconnection von NGNs. Heinrich Gebehenne 17. November 2006.

Zukunft der Netze 6. Fachtagung der ITG-FA 5.2. Interconnection von NGNs. Heinrich Gebehenne 17. November 2006. Zukunft der Netze 6. Fachtagung der ITG-FA 5.2. Interconnection von NGNs. Heinrich Gebehenne 17. November 2006. Interconnection im PSTN/ISDN. Das Interconnection erfolgt über ein globales Zeichengabenetz

Mehr

Betriebskonzept E-Mail Einrichtung

Betriebskonzept E-Mail Einrichtung Betriebskonzept E-Mail Einrichtung www.bolken.ch Klassifizierung öffentlich - wird an die E-Mail Benutzer abgegeben Versionenkontrolle Version Status Verantwortlich Datum 4.0 Genehmigt Gemeinderat 25.03.2015

Mehr

Next Generation Networks und UMTS

Next Generation Networks und UMTS Next Generation Networks und UMTS Ulrich Trick, Fachgebiet Digitale Übertragungstechnik - Telekommunikationsnetze, FH Frankfurt am Main, Kleiststr. 3, D-60318 Frankfurt/M., E-Mail: trick@e-technik.org

Mehr

Mobile Diensteplattform für neue SIP-basierte Mehrwertdienste. 12. Mobilfunktagung Osnabrück

Mobile Diensteplattform für neue SIP-basierte Mehrwertdienste. 12. Mobilfunktagung Osnabrück Mobile Diensteplattform für neue SIP-basierte Mehrwertdienste 12. Mobilfunktagung Osnabrück 30. - 31. Mai 2007 Dipl.-Ing. Sven Burdys (burdys@e-technik.org) Prof. Dr.-Ing. Ulrich Trick (trick@e-technik.org)

Mehr

Infomelde-Server Einstellungen

Infomelde-Server Einstellungen Genau im Auge behalten, was Ihnen wichtig ist... Seite Themen 1 Servereinstellungen 2 Störmeldungen / Regeln 3 Regeln erstellen 4 Master-Daten / Schlüsselbegriffe 5 Empfänger / Rückmelde-Aktionen 6 Apple

Mehr

Digitale Sprache und Video im Internet

Digitale Sprache und Video im Internet Digitale Sprache und Video im Internet Kapitel 6.3 MBONE 1 MBONE MBONE wurde entwickelt für den Transport von Multicast- Multimedia im Internet (etwa seit 1994) MBONE wird insbesondere von Forschungseinrichtungen

Mehr

SIP und DUNDi TM. Session Initiation Protocol und Distributed Universal Number Discovery. Florian Forster

SIP und DUNDi TM. Session Initiation Protocol und Distributed Universal Number Discovery. Florian Forster und DUNDi TM Session Initiation Protocol und Distributed Universal Number Discovery Friedrich Alexander Universität Erlangen-Nürnberg Seminar OpenSource Telefonie, 2005-06-16 http://verplant.org/uni/ost/

Mehr

Der TCP/IP- Administrator

Der TCP/IP- Administrator Detlef Knapp Praxishandbuch Der TCP/IP- Administrator Aufbau, Betrieb und Troubleshooting von TCP/l P-Netzen w _ Postfach rosnacn 12 n Ü 09 ua Fon 0 82 33/23-94 92 J^^INTEREST 86438 Kissing Fax 0 82 33/23-74

Mehr

Voice over IP - Die Technik

Voice over IP - Die Technik Voice over IP - Die Technik Anatol Badach Grundlagen und Protokolle für Multimedia-Kommunikation ISBN 3-446-40304-3 Inhaltsverzeichnis Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-40304-3

Mehr

Kapitel 4 Zugriffsbeschränkungen

Kapitel 4 Zugriffsbeschränkungen Kapitel 4 Zugriffsbeschränkungen In diesem Kapitel erfahren Sie, wie Sie Ihr Netzwerk durch Zugriffsbeschränkungen des 54 MBit/s Wireless Router WGR614 v6 schützen können. Diese Funktionen finden Sie im

Mehr

Grundlagen DNS 1/5. DNS (Domain Name System)

Grundlagen DNS 1/5. DNS (Domain Name System) Grundlagen DNS 1/5 DNS (Domain Name System) Weltweit gibt es 13 zentrale DNS-Server (Root-Nameserver), auf denen die verschiedenen Domains abgelegt sind. Der Domönennamensraum bzw. das Domain Name Space

Mehr

SDP ABNF (RFC4234) Session Initiation Protocol. Einleitung SDP Body. Anwendung

SDP ABNF (RFC4234) Session Initiation Protocol. Einleitung SDP Body. Anwendung SDP Body Anwendung SDP (vgl. 4566) bietet eine Beschreibung einer Session (z.b. Multimedia Konferenz) mit allen Informationen, die von Clients benötigt werden, um an der Session teilzunehmen: Name und

Mehr

Internet-Telefonie Voice over IP (VoIP) Horst Härtel. prowww. RMTS Gerd Rimner. Markus Kammann. Thomas Oehring

Internet-Telefonie Voice over IP (VoIP) Horst Härtel. prowww. RMTS Gerd Rimner. Markus Kammann. Thomas Oehring Internet-Telefonie Voice over IP (VoIP) Horst Härtel RMTS Gerd Rimner Thomas Oehring prowww Markus Kammann Agenda Grundlagen von VoIP Wie steige ich ein? Was kostet der Einstieg? Einsatzszenarien ?? Akustikkoppler

Mehr

VoIP - Protokolle. Somala Mang Christian Signer Jonas Baer

VoIP - Protokolle. Somala Mang Christian Signer Jonas Baer VoIP - Protokolle Somala Mang Christian Signer Jonas Baer Inhalt Motivation Protokolle SIP IAX2 Skype Vergleich Diskussion Seite 2 Motivation Schweizer CRM integriert Skype und Twixtel (http://www.inside-it.ch)

Mehr

TeamSIP und ENUM zwei sich ergänzende Lösungen

TeamSIP und ENUM zwei sich ergänzende Lösungen TeamSIP und ENUM zwei sich ergänzende Lösungen Dr.-Ing. Thomas Kupec TeamFON GmbH Stahlgruberring 11 81829 München Tel.: 089-427005.60 info@teamfon.com www.teamfon.com TeamFON GmbH 2007 Agenda Einführung

Mehr

SIP - Multimediale Dienste in Internet

SIP - Multimediale Dienste in Internet SIP - Multimediale Dienste in Internet Grundlagen, Architektur, Anwendungen von Stephan Rupp, Gerd Siegmund, Wolfgang Lautenschläger 1. Auflage SIP - Multimediale Dienste in Internet Rupp / Siegmund /

Mehr

Aufgabe 12.1b: Mobilfunknetzwerke

Aufgabe 12.1b: Mobilfunknetzwerke Aufgabe 12.1b: Mobilfunknetzwerke b) Welche Konsequenzen ergeben sich aus der Wahl einer bestimmten Zellgröße? für eine bestimmte Technologie ist die Anzahl der verfügbaren Kanäle pro Funkzelle begrenzt

Mehr

IMS Einordnung und Einführung

IMS Einordnung und Einführung IMS Einordnung und Einführung Seminarvortrag in der Arbeitsgemeinschaft Rechnerbetrieb Technische Fakultät Universität 2008, , IMS: Anwendungsgebiete Converged Services Provider

Mehr

Referat von Sonja Trotter Klasse: E2IT1 Datum Jan. 2003. Subnetting

Referat von Sonja Trotter Klasse: E2IT1 Datum Jan. 2003. Subnetting Referat von Sonja Trotter Klasse: E2IT1 Datum Jan. 2003 Subnetting Einleitung Thema dieser Ausarbeitung ist Subnetting Ganz zu Beginn werden die zum Verständnis der Ausführung notwendigen Fachbegriffe

Mehr

VRRP. Bild 004482 zeigt die Adressangaben in einem IP-Paket bei dessen Übermittlung über die Grenze eines IP-Subnetzes hinweg.

VRRP. Bild 004482 zeigt die Adressangaben in einem IP-Paket bei dessen Übermittlung über die Grenze eines IP-Subnetzes hinweg. VRRP Virtual Router Redundancy Protocol Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN 978-3824540662 Netzwerke auf Basis des Internet Protocol (IP)

Mehr

Einführung in Voice over IP

Einführung in Voice over IP Voice over IP (VoIP) Einführung in Voice over IP Voice over IP, auch Internet-Telefonie genannt, ist die Bezeichnung für Telefonieren über ein Computernetzwerk auf der Grundlage des Internet-Protokolls.

Mehr

DIE GRUNDLAGEN DER FERNÜBERWACHUNG

DIE GRUNDLAGEN DER FERNÜBERWACHUNG DIE GRUNDLAGEN DER FERNÜBERWACHUNG Verbraucherleitfaden Version 1.0 Deutsch Einleitung Derzeit sind am Markt zahlreiche Videoüberwachungssysteme erhältlich, die einen digitalen Zugriff über Netzwerkverbindungen

Mehr

Kurs 70-291 Notizen Rene Dreher www.renedreher.de -DNS (Domain Name System)

Kurs 70-291 Notizen Rene Dreher www.renedreher.de -DNS (Domain Name System) -DNS (Domain Name System) Das DNS ist ein weltweit auf tausende von Servern verteilter hierarchischer Verzeichnisdienst, der den Namensraum des Internets verwaltet. Dieser Namensraum ist in so genannte

Mehr

Collax Active Directory

Collax Active Directory Collax Active Directory Howto Dieses Howto beschreibt die Konfiguration eines Collax Servers um einer Windows Active Directory Service (ADS) Domäne beizutreten. Im Englischen spricht man hierbei von einem

Mehr

IP-Adressen und Ports

IP-Adressen und Ports IP-Adressen und Ports Eine Einführung Tina Umlandt Universität Hamburg 2. August 2011 Überblick Präsentationsablauf 1 IP = Internetwork protocol Schematische Darstellung über die Layer IP-Datenpaket (IPv4)

Mehr

The Cable Guy März 2004

The Cable Guy März 2004 The Cable Guy März 2004 Local Server-Less DNS-Namensauflösung für IPv6 von The Cable Guy Alle auf Deutsch verfügbaren Cable Guy-Kolumnen finden Sie unter http://www.microsoft.com/germany/ms/technetdatenbank/ergebnis.asp?themen=&timearea=3j&prod=

Mehr

Vorteile von Java und Konvergenz Service Creation mit JAIN Network Management mit JMX Fazit

Vorteile von Java und Konvergenz Service Creation mit JAIN Network Management mit JMX Fazit Hochschule für Technik und Architektur Chur Dr. Bruno Studer Studienleiter NDS Telecom, FH-Dozent bruno.studer@fh-htachur.ch 1 GSM: 079/610 51 75 Agenda Vorteile von Java und Konvergenz Service Creation

Mehr

SCHRITT FÜR SCHRITT DIE ENTWICKLUNG DES MOBILFUNKS VON GSM ZU UMTS

SCHRITT FÜR SCHRITT DIE ENTWICKLUNG DES MOBILFUNKS VON GSM ZU UMTS SCHRITT FÜR SCHRITT DIE ENTWICKLUNG DES MOBILFUNKS VON ZU UMTS Dr. Stephan Rupp, Franz-Josef Banet, Alcatel, Stuttgart INHALTSVERZEICHNIS DIE ENTWICKLUNG DES MOBILFUNKS VON ZU UMTS 1 1 ÜBERSICHT 2 2 DAS

Mehr

Router 1 Router 2 Router 3

Router 1 Router 2 Router 3 Network Layer Netz 1 Netz 2 Netz 3 Router 1 Router 2 Router 3 Router 1 Router 2 Router 3 Netz 1, Router 1, 1 Netz 1, Router 1, 2 Netz 1, Router 2, 3 Netz 2, Router 2, 2 Netz 2, Router 2, 1 Netz 2, Router

Mehr

Die at43 Breitband Kommunikationsplattform. Michael Haberler IPA/nic.at

Die at43 Breitband Kommunikationsplattform. Michael Haberler IPA/nic.at Die at43 Breitband Kommunikationsplattform Michael Haberler IPA/nic.at Vorstellung - nic.at &IPA nic.at ist das Registry für.at Domains entstanden aus Uni s und ISP s heute Tochter der gemeinnützigen Internet

Mehr

Netzwerke 2 Asterisk. Merkle, Matthias Prösl, Johannes Schätzle, Nicolas Weng, Daniel Wolf, David

Netzwerke 2 Asterisk. Merkle, Matthias Prösl, Johannes Schätzle, Nicolas Weng, Daniel Wolf, David Netzwerke 2 Asterisk Merkle, Matthias Prösl, Johannes Schätzle, Nicolas Weng, Daniel Wolf, David Inhalt Was ist Asterisk? Funktionsweise/Ablauf SIP H.323 Protokoll Versuchsaufbau Vor-/Nachteile Zukunftsaussichten

Mehr

2 Typische VoIP-Umgebungen

2 Typische VoIP-Umgebungen 2 Typische VoIP-Umgebungen Die Architekturen für den Dienst VoIP stehen fest. Hierbei wird zwischen H.323- und SIP-Architektur unterschieden. Sie sind in Abb. 2-1 und Abb. 2-2 dargestellt. Abb. 2-1: H.323-Architektur

Mehr

Installationsführer für den SIP Video Client Linphone

Installationsführer für den SIP Video Client Linphone Installationsführer für den SIP Video Client Linphone Stand: 10.04.2010 1. Einleitung Dieses Dokument beschreibt die Vorgehensweise für den Download, die Installation und Inbetriebnahme eines SIP Videoclients

Mehr

Client-Server-Prinzip

Client-Server-Prinzip Client-Server-Prinzip Kommunikation im Internet erfolgt nach dem Client-Server-Prinzip: Client sendet eine Anfrage (fordert eine Dienstleistung an) Server sendet die Antwort (bietet eine Dienstleistung

Mehr

ENUM. RRZN-Kolloquium WS 03/04. Uwe Oltmann RRZN. Electronic NUMbering. Regionales Rechenzentrum für Niedersachsen

ENUM. RRZN-Kolloquium WS 03/04. Uwe Oltmann RRZN. Electronic NUMbering. Regionales Rechenzentrum für Niedersachsen ENUM Electronic NUMbering RRZN-Kolloquium WS 03/04 Uwe Oltmann RRZN Überblick Definition von ENUM Technische Realisierung Nutzen und Risiken Feldtests und verfügbare Produkte Uwe Oltmann, RRZN 08.01.2004

Mehr

Offen und flexibel. Next Generation Network Neue Anwendungen und Dienste für Unternehmenskunden

Offen und flexibel. Next Generation Network Neue Anwendungen und Dienste für Unternehmenskunden Offen und flexibel Next Generation Network Neue Anwendungen und Dienste für Unternehmenskunden Das Netzwerk der nächsten Generation vereint Sprache, Daten und Video Neue Anwendungen und Dienste für Unternehmenskunden

Mehr

Technische Umsetzung von Überwachungsmaßnahmen in der Internet-Telefonie

Technische Umsetzung von Überwachungsmaßnahmen in der Internet-Telefonie Technische Umsetzung von Überwachungsmaßnahmen in der Internet-Telefonie Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen Referat IS 16 Sicherstellung der Telekommunikation

Mehr

Client-Server mit Socket und API von Berkeley

Client-Server mit Socket und API von Berkeley Client-Server mit Socket und API von Berkeley L A TEX Projektbereich Deutsche Sprache Klasse 3F Schuljahr 2015/2016 Copyleft 3F Inhaltsverzeichnis 1 NETZWERKPROTOKOLLE 3 1.1 TCP/IP..................................................

Mehr