IP Multimedia Subsytem (IMS) - AOT

Transcrição

IP Multimedia Subsystem
Agententechnologien in der
Telekommunikation Sommersemester
2009
Stefan Marx
[email protected]
Lecture 3 – 13.05.2009
AOT
Agententechnologien in
betrieblichen Anwendungen
und der Telekommunikation
Agenda
• IMS Einleitung (Überblick, Motivation)
• Session Initiation Protocol
•Einleitung
•Überblick SIP Session Aufbau und Registrierung
•SIP im Detail:
•Session Aufbau, Protokoll Nachrichten, Komponenten
•Session Aufbau/Kontrolle - Kombination mit SDP
•Security
•SIP Protokoll Erweiterungen (Presence & IM)
• IMS
•Überblick
•SIP Signalisierung im IMS
•Komponenten: CSCF, HSS
•Registration / Session Aufbau im Detail
•Service Ausführung / SIP AS / Integration mit Parlay, OMA
•Weitere Komponenten: MRF, BGCF, Charging
•Security
•IMS Integration NGN, IPTV
• Zusammenfassung
• Referenzen
AOT
2
TU Berlin
Ö Einleitung
Quelle: http://www.ikr.uni-stuttgart.de/Content/VFF_IKR_Workshop_2006/FMC_Network_Evolution.pdf
AOT
3
TU Berlin
Einleitung – IP Multimedia Subsystem – Motivation (1)
Not reusable
Horizontal layered architecture and
service integration
Quelle: Business Communications Review, May 2006
AOT
4
TU Berlin
Einleitung – IP Multimedia Subsystem – Motivation (2)
-> New network operators business model
Neue „bessere“
Dienste:
•z.B. bessere
Video Qualität
User profiles &
charging, AAA
•zugeschnitten
auf den Benutzer
(user context &
location)
IMS als Teil der
network operator
Architektur
Single-sign-on
Quelle: http://www.deutsche-telekom-laboratories.de/~vidales/pubs/commag-ieee_acuevas-final.pdf
AOT
5
TU Berlin
Einleitung – IP Multimedia Subsystem (1)
Voice
Video
New multimedia
realtime applications
Service
Integration
Data
kontrollierte und
personalisierte
Person-zu-Person
und Person-zucontent
Kommunikation
IMS
Open-Standard
Schnittstellen
Charging
Connectivity network
independence
Converged networks
AAA, QoS, Roaming
Single Sign On
AOT
6
TU Berlin
Einleitung – IP Multimedia Subsystem
Ö Spezifiziert vom Third Generation Partnership Project (3GPP/3GPP2)
t Ursprünglich als Teilspezifikation in Release 5 (2002) für 3G Mobilfunknetze /
UMTS
t Ab Release 6 (2004) WLAN Integration, ab Release 7 unabh. von
Zugangstechnologie
Ö IMS ist Industriestandard für Netze der nächsten Generation für Dienste wie VoIP,
Telefonie und Multimedia
Ö definiert generische Architektur mit Open-Standard Schnittstellen
t IMS-Standard beschreibt Funktionen der Netzelemente und Schnittstellen
zwischen ihnen (Reference Points)
t Definiert Mechanismen für: Sicherung der Dienstqualität (QoS), Roaming,
Abrechung der Multimedia Sitzung (charging), Integration von Diensten
Ö IMS Dienste bieten kontrollierte und personalisierte Person-zu-Person und Person-zucontent Kommunikation (Sprache, Text, Video,…)
AOT
7
TU Berlin
Einleitung – IMS – Motivation Zusammenfassung
Ö
Eine Service-orientierte Umgebung - Nutzung einer Vielzahl von Anwendungen unabhängig vom
darunter liegenden Zugriffsnetzwerk und dem verwendeten Endgerät
Ö
„layered“, horizontale Netzwerk Architektur
t Wiederverwendung der Funktionalitäten in verschiedenen Anwendungen
t ermöglicht Service Providern schnelle, einfache und kostengünstige Entwicklung/Einführung
neuer VoIP- und Multimedia-Dienste basierend auf einer standarisierten Architektur
Ö
Ö
Gemischte Multimedia-Anwendung - einfache Kombination; keine Trennung zwischen Daten-, Video-,
und Audio-Applikationen
Security
t authentication, authorization, privacy
t single-sign-on; nach Registrierung Nutzung aller für den Benutzer freigeschalteten Dienste
Ö
Quality of Service – garantierte Qualität der Kommunikation
Ö
Charging, Billing
Ö
Neue Anwendungen - Videokonferenz, Push-to-Talk (Push-to-X), multiparty gaming, community
services, content sharing, Presence-Management (kombiniert mit location based services)
Ö
Roaming – Nutzung der Dienste aus fremden Netzwerken
AOT
8
TU Berlin
IMS / NGN History
(UMTS)
AOT
9
TU Berlin
Migration zu IMS
Mobile networks (GSM)
IMS
Quelle: Alcatel
AOT
10
TU Berlin
IMS - Architektur Überblick (1)
Ö
Ö
3 Layer Architecture
Service Layer :
t telephony & multimendia apps
t IMS Enablers: specific generic
ASs; e.g. presence, group mgt.
t value-added services (push-totalk, …)
Ö
Control Layer:
t End point registration
t Session setup
t Media Servers (MRF)
t Signaling/Media Gateways
(SG/MGCF)
Ö
Connectivity Layer
t Verbindung unterschiedlicher
Zugangsnetze zu IMS (über
Gateways)
AOT
IMS
Quelle: „White Paper IMS - IP Multimedia Subsystem“, Ericsson
11
TU Berlin
IMS - Architektur Überblick (2)
“Reference points
describe all the traffic
between two resources,
including multiple
protocols for the
different types of traffic.
IMS reference points not
only specify how to
interact with a resource
but also which
endpoints are allowed to
interact with a specific
resource.”
Quelle:
http://www.bcr.com/carriers/public_networks/ims_101_w
hat_need_know_now_2005061514.htm
AOT
Quelle: http://www.3gpp.org/specs/specs.htm
12
TU Berlin
IMS – verwendete IP Protokolle
Ö Schlüsselprotokoll:
Session Initiation
Protocol (SIP)
t SignalisierungsProtokoll zum Aufbau,
Abbau und
Modifikation von
Multimedia Sitzungen
im Internet
IMS
Ö Diameter basierte AAA
(Authentication,
Authorisation,
Accounting)
Ö und andere: SDP, RTP,
RTCP, MGCP, Megaco
(H.248), COPS, …
AOT
User Equipment (UE)
Quelle: „White Paper IMS - IP Multimedia Subsystem“, Ericsson
13
TU Berlin
Ö Session Initiation Protocol
AOT
14
TU Berlin
Session Initiation Protocol - Einleitung
Ö Signalisierungs-Protokoll zum Aufbau, Abbau und Modifikation von multimedia
Sitzungen im Internet
t Audio/Video IP Telephonie / Konferenzen
t Instant Messaging, User Presence, gaming, distributed media, …
Ö einfach strukturiert, leicht erweiterbar und offen
t request-response protocol,
t text-basiert ähnlich HTTP auf der Applikationsebene
t setzt auf Transport Protokollen wie UDP und TCP auf
Ö Standardisiert von der IETF in mehreren RFCs
t Kernprotokoll: erstmals im RFC 2543 (1999); aktuelle Spezifikation im RFC
3261 (2002); dazu zahlreiche RFCs zu Erweiterungen
Ö breite Unterstützung der führenden Telekommunikationshersteller, Standard
der 3GPP/3GPP2 für multimediale Kommunikation
AOT
15
TU Berlin
SIP Session Setup (1)
Quelle: http://www.iaria.org/conferences2007/filesICDT07/tutorial-ims-6.pdf
AOT
16
TU Berlin
AOT
17
TU Berlin
AOT
18
TU Berlin
SIP - Registering
AOT
19
TU Berlin
SIP – Session Setup using SIP Proxies (1)
AOT
20
TU Berlin
SIP – Session Setup using SIP Proxies (2)
AOT
21
TU Berlin
Überblick SIP Funktionalitäten
Ö Kombinierter Einsatz mit
t Session Description Protocol (SDP) zum Beschreiben der Media
Attribute
t Realtime Transport Protocol (RTP) zum Übertragen der eigentlichen
media stream Daten
Ö Funktionalitäten :
t Ermitteln Ort bzw. Endgerät des Anzurufenden und Bereitwilligkeit zur
Teilnahme an Kommunikation
t Verbindungsaufbau und -Verwaltung (Aushandeln und Modifizieren
der Verbindungsparameter)
t Feststellen der Endgerät Fähigkeiten
t Erweiterungen ermöglichen u.a. user presence awareness und Instant
Messaging
AOT
22
TU Berlin
SIP - Basic requests (RFC 3261)
t REGISTER: Registrieren der gegenwärtige location eines Clients
t INVITE: Initiieren eines Anrufes, Media (Neu-)Aushandlung
t ACK: Client bestätigt Eintreffen einer INVITE - 200 OK Antwort
vom Server
t BYE: Teilnehmer beendet Anruf
t CANCEL: bricht vorhergehend gesendeten request ab
t OPTIONS: UAC erfragt die Fähigkeiten eines UAS; der UAS
reagiert wie bei einem INVITE ohne einen Anruf zu initialisieren
AOT
23
TU Berlin
SIP - Protokoll (1) – Messages - Requests
Ö SIP request Aufbau :
t request-line (mit request
Methode und Ziel URI),
t mehrere header lines,
t leere Zeile,
t optionaler message body
(message payload)
INVITE sip:alice@domain2 SIP/2.0
Call-ID:
[email protected]
CSeq: 4 INVITE
From: „Bob" <sip:bob@domain1>;tag=6043
To: „Alice" <sip:alice@domain2>
Via: SIP/2.0/UDP 192.168.1.2:15890;
branch=z9hG4bK71d20bccbea3e3c145dc60466c44fb
Max-Forwards: 70
Route: <sip:130.149.159.218:5060>
Content-Type: application/sdp
Contact:
<sip:192.168.1.2:15890;transport=udp>
Content-Length: 87
v=0
o=- 3326598528 3326598528 IN IP4 192.168.1.2
s=c=IN IP4 192.168.1.2
...
AOT
24
TU Berlin
SIP - Protokoll (2) - Messages - Responses
Ö
Ö
Ö
Ö
status-line enthält status code und Kurzbeschreibung der Antwort,
Status code geteilt in 6 Klassen :
t 1xx : informelle Antwort, „Session in Progress“ o. „Ringing“
t 2xx : success, request ist akzeptiert
t 3xx : redirection des requests, der Sender hat den request an neue(n)
Empfänger zu richten
t 4xx : client error – syntaktischer Fehler im request oder request kann
vom server nicht bearbeitet werden
t 5xx : server error – Fehler im server beim Abarbeiten des requests
t 6xx : global error – Fehler in allen servern (vom proxy gesetzt)
man unterscheidet „provisional“ (1xx) und „final“ (alle anderen)
Antworten
t einem request sind mehrere provisional (nur bei INVITE) und eine final
response von einer remote Instanz einer SIP Entität zugeordnet
200 OK SIP/2.0
Call-ID: …
CSeq: 4 INVITE
From:
To: …
Contact: …
…
v=0
o=- 3326598528...
s=c=IN IP4
192.168.1.2
...
sind mehrere (remote) Instanzen registriert, können auch mehrere final
Antworten eintreffen (oder werden vom SIP proxy server absorbiert)
AOT
25
TU Berlin
SIP - Session Signalling Flow (1)
Ö
Anruf Initialisierung, Media Strom
Aushandlung
(audio/video media stream)
Ö
Modifikation der Medienströme
(re-INVITE)
Ö
Anruf Beendigung
AOT
26
TU Berlin
SIP - Session Signalling Flow (2)
Quelle: „Understanding SIP“, D. Sisalem and J. Kuthan
AOT
27
TU Berlin
SIP - Session Stream Negotiation & Description
Ö
Ö
Session Description Protocol (SDP) (RFC 2327) :
Offer :
session stream Attribute werden vom
beschrieben (als body in SIP messages)
v=0
o=- 25678 753849 IN IP4
t U.a. Empfänger IP Addresse und Port, media
128.96.41.10
type, Protokoll, Codecs, Name und Zweck
s=
der Session, Startzeit
c=IN IP4 128.96.41.10
t=0 0
m=audio 3456 RTP/AVP 0 8
m=video 75464 RTP/AVP 32
Aushandlung erfolgt per offer-answer mechanism
(RFC 3264)
t Herausfinden der codecs die von beiden
Teilnehmern unterstützt werden
Answer :
t SIP messages enthalten offer/answer als
v=0
SDP body, wenn kein body Æ offer
o=- 25678 753849 IN IP4
requirement (nur INVITE)
128.96.41.5
t Gebräuchlich im INVITE / 200 OK message
s=
Paar (aber auch : 200 OK / ACK, 183 /
c=IN IP4 128.96.41.5
PRACK)
t=0 0
t Neuaushandlung der streams durch Senden
m=audio 54377 RTP/AVP 8
eines neuen offers (re-INVITE oder UPDATE),
m=video 0 RTP/AVP 32
t Beenden/Verwerfen und Hinzufügen von
streams
AOT
28
TU Berlin
SIP Registrar Server
Ö Erreichbarkeit für andere Benutzer :
gewährleistet durch Registrierung am
registrar server
Location Database Eintrag
„Benutzer sip:name@domain ist
erreichbar unter IP + port“
Ö SIP Entitäten sind eindeutig identifiziert
durch eine SIP URI (Uniform Resource
Identifier), sip:username@domain
Ö User Agent registriert seine derzeitige
location (IP address + port) mit SIP URI
(address-of-record) des Benutzers durch
REGISTER request
Ö Benutzer kann über mehrere Endgeräte
gleichzeitig erreichbar sein
Ö In Kombination HTTP Digest Authentication
(RFC 2617) zur Benutzer Authentifizierung
AOT
29
TU Berlin
SIP Proxy Server
Ö Routet die SIP messages vom UAC zum UAS, und zurück
Ö Proxy Server muß nächsten Hop bestimmen, möglich durch :
t DNS, registrar (location database), Benutzerskript, fest konfiguriert
t Ist meist co-located mit einem registrar
Ö Verändert bestimmte Teile der requests vor dem Weitersenden; ermöglicht u.a.:
t routen der Responses (Proxy Adresse in Via-header) zurück zum UAC
t Record-Routing: Proxy bleibt im SIP signaling path einer session
Ö Man unterscheidet stateless und stateful proxy
t Stateful : hält Transaction (Zuordenen von responses zu requests), forking
möglich, Absorbieren von retransmissions
t Stateless : schneller, skalierbar, produziert mehr traffic
AOT
30
TU Berlin
SIP Proxy Forking
Ö Der Angerufene ist an mehreren Endgeräten gleichzeitig registriert
Ö Proxy kann request an mehrere Engeräte des Angerufenen weiterleiten
Ö Bei Rufannahme : Zurückreichen der ersten „OK“ Antwort (von (2)), Abrechen (CANCEL
Methode) der anderen Einladung (1)
EL
CANC
Callee instance (1)
Callee instance (2)
Caller
AOT
31
TU Berlin
SIP Komponenten
ÖUser Agent (UA) :
t
Benutzerendgerät (Softphone, Hardphone, auch
Application Server u. PSTN GW)
t
UA Client (UAC): initiiert Anrufe, sendet SIP Anfragen
t
UA Server (UAS): hört auf eingehende Anrufe,
sendet SIP Antworten
SIP
proxies
(optional)
…
ÖProxy Server :
t
routet SIP Nachrichten zw. SIP Entitäten
ÖRegistrar Server :
t
registriert Bindung zw. Benutzer und Endgerät
SIP AS
+ Registrar
ÖRedirect Server :
t
leitet SIP requests zu neuer(/n) location(s) (per 3xx
response mit neuem contact(s))
ÖBack-to-Back User Agent (B2BUA)
t
terminiert SIP Anfragen (UAS) und generiert neue
(UAC)
t
Manipulation von SIP messages
SIP Trapezoid mit UA und proxy server
AOT
32
TU Berlin
SIP - Sicherheitsmechanismen
Ö Authentifizierung des request-Senders
t HTTP Digest authentication scheme benutzt im
SIP Protokoll
t Nach Erhalt von 401/407 response wird
request nochmal mit Benutzer credentials
(Name, realm und Passwort) versendet
UA
Proxy Server /
Registrar
REQUEST
407 Proxy Authorization
Required
REQUEST
Authentication-header
with user credentials
200 OK
Ö Integrität und Vertrauenswürdigkeit
t S/MIME Standard (RFC 3851) für digitale
Signaturen und Verschlüsselung des SIP
message bodies
Ö Verschlüsselter Transport
t SIPS URI (“sips:” Schema anstatt von “sip:”)
als request-URI
t TLS Protokoll zum Senden des requests hopby-hop bis zum proxy server der Ziel-Domain
AOT
33
TU Berlin
SIP Erweiterungen – Presence and Instant Messaging
Ö Spezifikationen von der IETF SIMPLE Working Group
Ö Konform zu generischen IM und presence Spezifikationen der
IETF (CPP, CPIM, IMPP WG) -> Interoperabilität zw. versch. IM
Protokollen (z.B. SIP zu XMPP über Gateways)
Presentity
Watcher
SUBSCRIBE
200 OK
Ö Presence services definiert im „presence event package“
t
t
t
Basiert auf generellem Event Notification Framework –
SUBSCRIBE / NOTIFY Methoden (RFC 3265) und
Event State Publishing, PUBLISH Methode, RFC 3903, Event
State Compositor und Event Publishing Agent
User presence beschrieben durch das Presence Information
Data Format (PIDF)
t
AOT
(un)SUBSCRIBE
200 OK
Sender
Ö Instant Messaging, two approaches :
t
NOTIFY (event state)
200 OK
pager mode: MESSAGE Methode, RFC 3428, stand-alone
Instant Messages über den SIP Signalisierungsweg
session mode : per INVITE ausgehandelt, Daten per MSRP
(Message Session Relay Protocol) peer-to-peer
34
Instant Inbox
MESSAGE
200 OK
(SIP UA)
(SIP UA)
TU Berlin
SIP Erweiterungen – Presence and Instant Messaging Presence Information Data Format (PIDF)
…
<presence xmlns="urn:ietf:params:xml:ns:pidf"
… entity="pres:[email protected]">
NOTIFY sip:10.0.4.62:43313;
<dm:tuple id="eadcddf7">
transport=udp SIP/2.0
<contact>sip:10.0.4.177:65093</contact>
Event: presence
<status><basic>open</basic></status>
Subscription-State:
<timestamp>2008-04-27T05:31:56Z</timestamp>
active;expires=3600
</dm:tuple>
Record-Route:
<dm:tuple id="eadcddf8">
<sip:130.149.154.198:5080;lr>
<contact>mail:[email protected]</contact>
Content-Type: application/pidf+xml
Content-Length: 1047
</dm:tuple>
…
<dm:person id="eabfccd3">
Benutzer sip:[email protected] ist (mit seinem SIP
<dm:timestamp>…</dm:timestamp>
Endgerät) unter der IP Adresse
<rpid:activities>
10.0.4.177:65093 bereit zur Kommunikation
<rpid:busy/>
(tuple Status der SIP Kontaktes ist „open“),
</rpid:activities>
er ist aber zur Zeit beschäftigt (Status
</dm:person>
person = „busy“). Weiterhin ist er per email </presence>
Request :
Body:
erreichbar (tuple Status ist „open“).
AOT
35
TU Berlin
SIP Erweiterungen – Presence and Instant Messaging - SIP
Presence Server
SUBSCRIBE
Presence Server
Quelle: http://download.oracle.com/docs/cd/E10301_01/doc.1013/e10292/about_sdp.htm
AOT
36
TU Berlin
SIP Erweiterungen – Event Notification
Ö Event Notification Framework
(SUBSCRIBE/NOTIFY/PUBLISH) ist generisch, beliebig
erweiterbar
Ö weitere definierte event packages :
t registration event package : Informationen über registrierte
SIP Entitäten
t reference event package : „kontaktiere third-party und teile
Erbgebnis mit !“ (session mobility, session hand-off)
t conference event package : Informationen über Konferenz
Teilnehmer/Status
t watcher info event template-package : Informationen über
subscriber für einen bestimmten event und notifier
AOT
37
TU Berlin
Ö IP Multimedia Subsystem
AOT
38
TU Berlin
IMS - Architektur Überblick
Ö
Service Layer (Application Layer)
t Application Server (AS)
t IMS Enablers (specific generic
ASs; e.g. Presence, Group
Management.)
Ö
Service Control Layer (IMS Core)
t Call Session Control Function
(S-, I-, P- CSCF)
t Home Subscriber Server
t Media Resource Function
(MRF)
t Media Gateway (SG/MGCF)
t Policy Decision Function (PDF)
t Charging Function
t Breakout Gateway
IMS
ÖUser Equipment (UE)
AOT
39
TU Berlin
IMS – User Identity
ÖUser Equipment = 3GPP IMS konformer SIP User Agent
ÖUE enthält ISIM / USIM (IP Multimedia / Universal Subscriber Identity Module) mit :
t Security key (für Benutzer Authentifizierung und Integrität/Verschlüsselung der SIP Nachrichten)
t Öffentliche und private Benutzer IDs sind dort gespeichert
t Home Network Domain URI
t USIM : temporäre private identity und public identity werden zugewiesen (berechnet aus IMSI
(International Mobile Subscriber Identitfication)
ÖIP Multimedia Private Identity (IMPI)
t Genau eine pro IMS subscriber, benutzt für AAA
ÖIP Multimedia Public Identity (IMPU)
t Normale SIP URI oder TEL URI
t Benutzt zum Routen der SIP messages
t Identifiziert den Benutzer öffentlich
t Mehrere public identities per IMS subscription möglich -> Benutzer agiert unter
verschiedenen Rollen -> Nutzung unterschiedlicher Dienste über zugewiesene Benutzer Profile
AOT
40
TU Berlin
IMS – SIP Signalling - Ohne Roaming
AOT
41
TU Berlin
IMS – SIP Signalling - Mit Roaming
AOT
42
TU Berlin
IMS – SIP Signalling - QoS
PDF – Policy Decision Function : Durchsetzen der auf Applikationsebene geforderten Media
Qualitäten auf Netzwerk Ebene (PDP context activation)
AOT
43
TU Berlin
IMS – SIP Signalling – Charging
Quelle: http://www.deutsche-telekom-laboratories.de/~vidales/pubs/commag-ieee_acuevas-final.
/ SCF
CCF - Charging Collection Function / SCF - Session Charging Function
44
AOT
TU Berlin
IMS - Call Session Control Function (CSCF)
Quelle : http://www.newport-networks.com/downloads/DaveGladwinSBCsAndIMS.pdf
AOT
45
TU Berlin
IMS - Proxy CSCF (P-CSCF)
Ö
Erster Kontaktpunkt (outbound proxy) im lokalen oder besuchten Netzwerk
t vom UE ausfindig gemacht über DHCP oder GPRS PDP
Ö
Agiert als proxy :
t Weiterleiten der SIP registration vom UE zum I-CSCF des Home Netzwerks
t Weiterleiten der SIP requests vom UE zum S-CSCF (oder I-CSCF) des Home
Netzwerks
t Weiterleiten der eintreffenden SIP Nachrichten zum UA
Ö
Enthält PDP(Policy Decision Point) / PDF (Policy Control Function) :
t ermittelt der QoS Klasse und Trägerquellen
t Prüft Media Parameter (SDP) gegen lokale policies
Ö
Komprimieren und Dekomprimieren (SigComp) von SIP Nachrichten zwischen UE
und P-CSCF
Ö
Aufbau Security Association zwischen UE und P-CSCF (SIP über IPSec)
Ö
Weitere Funktionen :
t Protokollierung,
t Aufruf Services in der lokalen Infrastruktur: Notrufunterstützung
AOT
46
TU Berlin
IMS - Serving CSCF (S-CSCF)
Ö
Agiert als Registrar; während Registrierung :
t
Authentifizieren des Benutzers (), holt dazu „authentication vector“ vom HSS
über Diameter MAR request
t
Holt user profil (zum späteren routen weiterer requests) vom HSS über
Diameter SAR request
Ö
Agiert als SIP Proxy
Ö
Ist immer im SIP Signalisierungs Pfad (Record-Routing + Service-Route)
Ö
Interagiert mit den Dienstplattformen, routet SIP request zu SIP AS
t
Filterinformation (im Benutzer Profil, vom HSS) bestimmen, ob und welcher AS
einen Dienst ausführen soll
Ö
Notifiziert SIP Entitäten über Eintreten eines Registrierungsereignisses (DeRegistrierung, Re-Authentifikation)
Ö
Führt netzwerkinitiierte De-Registrierung und Anruf Beendigung aus
AOT
47
TU Berlin
IMS - Interogating CSCF (I-CSCF)
Ö
Zentraler Kontaktpunkt für alle SIP requests zum subscriber eines Operator
Netzwerks
Ö
Registrierung: Zuweisung eines S-CSCF zum Benutzer (über HSS Diameter Anfrage)
Ö
Routed SIP requests zu diesem S-CSCF
Ö
Versteckt interne Struktur eines Operators - THIG (Topology Hiding Inter-Network
Gateway)
t Immer im SIP Signallisierugspfad Pfad durch Record-Routing und Service-Route;
Verschlüsselung der Einträge des zu schützenden Netzwerks in SIP messages
AOT
48
TU Berlin
IMS – Home Subscriber Server (HSS)
Ö
Verwaltet die Benutzer Subscription / Profil Informationen
t Authentifizierungsinformationen
t Private und Public Identitäten der Benutzer
t Filter Kritierien -> welche services werden aufgerufen ?
t Über welche Medien darf Benutzer kommunizieren
Ö
Cx (Diameter) Schnittstelle zu S-CSCF, I-CSCF
t Liefert Authentifizierungs Daten und Benutzer Profil an S-CSCF
t Liefert zugewiesenen S-CSCF an I-CSCF
Ö
Sh (Diameter) Schnittstelle zu Application Server
t Liefert Benutzer Datenan AS (public IDs, welcher S-CSCF ?, registration state, location information, charging
information, …)
t Notifiziert AS über dis Änderung von Benutzer Daten
t AS kann Benutzer Profil setzen
Ö
Mehrere HSS Instanzen erlaubt, verwaltet von SLF
(Subscription Location Function)
AOT
49
TU Berlin
IMS - Registrierung und Session Aufbau
AOT
50
TU Berlin
IMS - Session Initiierung mit Service Aufruf
Serving Network A
Serving Network B
Access Network A
Service Platform A
(ASA )
Service Platform B
(ASB)
SIP / SDP
SIP / SDP
Gm
SIP/SDP
inviting
[email protected]
I -CSCF
A
S-CSCFA
S -CSCFB
I -CSCFB
PDF
Gm
Go
SGSN GGSN
UEA
P-CSCFD
SIP / SDP
P-CSCFC
PDF
Access Network B
Go
SIP/SDP
GGSN SGSN
Data- Path
IP Backbone Network
UEB
PDP Context
Sessionlevel(SIP/SDP signalling)
Bearer level(PDPcontext activation / modification /Release)
Interactionbetweensession andbearer level(COPS)
I-CSCF (between P-CSCF and S-CSCF) not shown for simplicity
PDP Context
Quelle: http://europe.eu.int/information_society/policy/ecomm/doc/info_centre/public_consult/ngn/comments/coureau.ppt
AOT
51
TU Berlin
IMS – Application Server /
Service Trigger Points (1)
Ö
Initial Filter Criteria
t Filter Regeln im Benutzer Profil; genau einer öffentlichen Benutzer ID zugeordnet
t Enthält Trigger Point + AS Indentifier (SIP URI format e.g. sip:[email protected])
Ö
Trigger Point = boolean expression -> unter welchen Bedingungen wird zum Application
Server geroutet?
Ö
Trigger Point =
Konjunktion/Disjunktion von
1..n Service Point Trigger
Ö
Service Point Trigger (SPT) :
Request URI, SIP Methode,
SIP Header, Session
Description, session case
(orginating or terminating)
Quelle: http://www.fokus.gmd.de/testbeds/ims_playground/Paper/FOKUS-IMS-Tutorial-public.pdf
AOT
52
TU Berlin
IMS – Application Server /
Service Trigger Points Example
<InitialFilterCriteria>
<Priority>0</Priority>
<TriggerPoint>
all calls from boss have to go
<ConditionTypeCNF>1</ConditionTypeCNF>
to an answering machine (SIP AS)
<SPT>
<ConditionNegated>0</ConditionNegated>
<Method>INVITE</Method>
(method=INVITE) AND
</SPT>
(P-Asserted-Identity =
<SPT>
<ConditionNegated>0</ConditionNegated>
sip:boss@domain) AND
<SIPHeader>
<Header>P-Asserted-Identity</Header>
<Content>sip:boss@domain</Content>
</SIPHeader>
</SPT>
</TriggerPoint>
<ApplicationServer>
<ServerName>sip:[email protected]:5100</ServerName>
<DefaultHandling>0</DefaultHandling>
</ApplicationServer>
</InitialFilterCriteria>
AOT
53
TU Berlin
IMS – Application Server - Modes
Ö
AS Dienste angeboten von home, visited oder third party provider
Ö
S-CSCF forwards requests to AS, results of AS sent back to S-CSCF
Ö
AS kann in 4 verschiedenen Modi agieren:
terminating UA or redirect server originating UA
SIP proxy
B2BUA
Ö
Public Service Identities (PSIs) zum Identifizieren bestimmten Application Server
t
AOT
Form einer SIP URI oder TEL URI, z.b: sip:[email protected]
54
TU Berlin
IMS – Application Server - Types
Ö SIP Application
Server
Ö OSA / Parlay
Services
Ö CAMEL
Services
AOT
55
TU Berlin
IMS – SIP Application Server – SIP Servlets
- Eine Realisierungsmöglichkeit für SIP AS sind SIP Servlets
- Definiert in Java Specification Request 289 (früher JSR 116)
AOT
56
TU Berlin
IMS – Application Server – OSA/Parlay
Services: Third Party Call, Conferencing, Terminal Status/Location, Messaging,
Presence, Audio Call, Streaming, Call Handling, Address Lists, …
AOT
57
TU Berlin
IMS im Kontext von OSA/Parlay, Parlay X, OMA
•Open Mobile Alliance (OMA)
•Zusammenschluss MobilfunkDienstleistungs- und
Produktanbieter
•Standardisierung von Diensten,
z.B. Presence und Group List
Enabler (XDMS)
•Parlay Group
IMS Core
•Abstraktion von Diensten
•Zusammenarbeit 3GPP
•Parlay - IDL für CORBA
•Parlay X - SOAP Web Services
AOT
Quelle: http://www-128.ibm.com/developerworks/webservices/library/ws-soa-ipmultisub1/
58
TU Berlin
IMS – Media Resource Function
Ö
Media Server Funktionalität, bietet Dienste wie
conferencing, streaming, announcement, recording
Ö
Media Resource Function is geteilt in zwei Funktionalitäten
t Media Resource Control Function (MRFC)
t Media Resource Processor Function (MRPF)
Ö
MRFC
t Interpretiert die SIP/SDP Signalisierungs Informationen
vom S-CSCF / AS
t Agiert als SIP User Agent zum S-CSCF hin
t Kontrolliert MRPF über H.248 Protokoll; Alternative:
(aber nicht standarisiert) SIP oder Integration MRFP und
MRFC in eine Komponente (da weniger komplex)
Ö
MRPF
t Mixing, streaming, transcoding
AOT
59
TU Berlin
IMS – Media Gateway
Ö Media Gateway Control Function (MGCF) - Gateway to PSTN networks
t Übersetzt SIP Nachrichten in entsprechende PSTN Signale und zurück
t Transcodiert codecs der Medienströme
t Agiert als SIP UA
Ö Breakout Gateway Control Function (BGCF)
t für Anrufweiterleitung vom IMS zum circuit switched network zuständig (Anruf
Telefonnummer, PSTN / Public Land Mobile Network (GSM))
t lokale MGCF (Anrufer im selben Netz) oder BGCF des fremden Netzes
AOT
60
TU Berlin
IMS – Charging
/ SCF
Ö Two approaches :
t Offline charging
t Online charging
Offline Charging : users pay for their services periodically (e.g. at the end of month)
Ö Charging Collection Function (CCF)
t collecting of Session charging information from the IMS nodes (by using Rf
interface (Diameter))
t intermediate data storage buffering; call detail records (CDR)
t transfer of the charging data to the (operator’s chosen) billing systems (BS)
Online Charging: Prepaid Service, credit based charging
Ö Session Charging Function (SCF) = AS, erhält “blind” SIP requests über User
Profil Filterregeln
61
AOT
TU Berlin
IMS – Sicherheitsaspekte
Ö
1: Beidseitige Authentifizierung zw. UE und Heimatnetzwerk über geheimen Schlüssel in
ISIM und HSS (assoziiert zu privaten Benutzer Identität (IMPI)) bei der SIP Registrierung
(3GPP Authentication and Key Agreement (AKA) Mechanismus)
Ö
Security Associations (IPSec, ESP
Verschlüsselung und Integrität)
t
2: zw. UE und P-CSCF;
aufgebaut bei SIP Registrierung
t
3: Cx Interface zw. HSS und xCSCF
t
4: inter domain über Security
Gateways (SEGs)
t
5: intra domain zw. x-CSCFs
Quelle : ETSI TS 33.203-710
AOT
62
TU Berlin
IMS – NGN Integration
Ö ETSI TISPAN aims to enable
Next Generation Networks
Ö 3GPP IMS as core of NGN
Ö A multi-service, multiprotocol, multi-access, IP
based network
Ö + Connectivity Control
Layer
t Network Attachment
Subsystem
t Resource Admission
Control Subsystem
Quelle: Introduction to TISPAN NGN, [email protected]
AOT
63
TU Berlin
IMS – NGN Integration am Bsp. von IPTV
NGN / IMS
based
IPTV
architecture,
TISPAN
TS 182 027
IPTV Service
Control
Functions
Ut
Xa
SSF
IPTV Media
Control Functions
CoD-MCF
CoD-SCF
SDF
BC-MCF
BC-SCF
Sh
N-PVR-MCF
Sh
N-PVR-SCF
Xp
Application and
ISC IPTV Service
Functions
UPSF
Cx
UE
y2
ISC
Gm
Core IMS
IPTV Media Functions
IPTV Media
Delivery Functions
CoD-MDF
Gq'
e2
BC-MDF
NASS
RACS
N-PVR-MDF
e4
Transport Control
Functions
Media Delivery,
Distribution & Storage
Transport Functions
Xc
Transport Processing
Functions
Xd
Quelle folgende Seiten : http://isoc.nl/activ/2008-SIPSIG-standards-OskarVanDeventer-IMS-basedIPTV.ppt
AOT
64
TU Berlin
IMS – NGN Integration am Bsp. von IPTV (2)
Ut
Xa
SCF and SDF:
IPTV Media
dedicated SIP
Control Functions
CoD-MCF
application
BC-MCF
servers for
N-PVR-MCF
IPTV
IPTV Service
Control
Functions
SSF
CoD-SCF
SDF
BC-SCF
Sh
Sh
N-PVR-SCF
Xp
Application and
ISC IPTV Service
Functions
UPSF
Cx
UE
Core IMS:
IPTV Media
Bunch of SIP
Delivery Functions
servers and User
CoD-MDF
Profile Server
BC-MDF
“HSS”
N-PVR-MDF
y2
ISC
Gm
Core IMS
Gq'
e2
NASS
RACS
e4
Transport Control
Functions
Xc
Xd
AOT
Media Delivery,
UE: User Equipment
Set-top
Functions box, Residential Gateway,
Home-Theater PC, …
Transport Functions
65
TU Berlin
Service
Media control andIPTV
delivery,
Control
Functions
e.g.SSF
video-on-demand
CoD-SCF
jukebox
SDF
IPTV Media
Control Functions
Ut
Xa
CoD-MCF
BC-MCF
BC-SCF
Sh
N-PVR-MCF
Sh
N-PVR-SCF
Xp
Transport, network
attachment,
UPSF
resource reservation
Application and
ISC IPTV Service
Functions
Cx
UE
IPTV Media
Delivery Functions
y2
ISC
Gm
Core IMS
CoD-MDF
Gq'
e2
BC-MDF
NASS
RACS
N-PVR-MDF
e4
Transport Control
Functions
Transport Functions
Xc
Media Delivery,
Functions
Xd
AOT
66
TU Berlin
IPTV Service
Control
Functions
Ut
Xa
SSF
IPTV Media
Control Functions
CoD-MCF
CoD-SCF
SDF
BC-MCF
SDF: Service Discovery Function,
N-PVR-MCF
N-PVR-SCF “what are my IPTV services”,
“where
can I change my user
Application
and
IPTV Service
Functions
profile”, “where can I select my
IPTV Media
service”, address
of service portal
Delivery Functions
BC-SCF
Sh
Sh
Xp
UPSF
ISC
Cx
UE
y2
ISC
Gm
Core IMS
CoD-MDF
Gq'
e2
BC-MDF
NASS
RACS
N-PVR-MDF
e4
Transport Control
Functions
Transport Functions
Xc
Media Delivery,
Functions
Xd
AOT
67
TU Berlin
IPTV Service
Control
Functions
Ut
Xa
SSF
IPTV Media
Control Functions
CoD-MCF
CoD-SCF
SDF
BC-MCF
SSF: Service Selection Function,
N-PVR-MCF
N-PVR-SCF
getting an Electronic Programme
Guide,
“what programs are available”
Application and
BC-SCF
Sh
Sh
Xp
UPSF
ISC
Cx
UE
IPTV Service
Functions
IPTV Media
Delivery Functions
y2
ISC
Gm
Core IMS
CoD-MDF
Gq'
e2
BC-MDF
NASS
RACS
N-PVR-MDF
e4
Transport Control
Functions
Transport Functions
Xc
Media Delivery,
Functions
Xd
AOT
68
TU Berlin
SCF: Service
Control Function,
Set up an IPTV
session using SIPbased session
control, select
Media Function
Xa
UE
IPTV Service
Control
Functions
Ut
SSF
IPTV Media
Control Functions
CoD-MCF
CoD-SCF
SDF
BC-MCF
BC-SCF
Sh
N-PVR-MCF
Sh
N-PVR-SCF
Xp
Application and
ISC IPTV Service
Functions
UPSF
Cx
IPTV Media
Delivery Functions
y2
ISC
Gm
Core IMS
CoD-MDF
Gq'
e2
BC-MDF
RACS: Resource &NASS
RACS
Control
Admission Control Transport
Functions
Transport Functions
Subsystem
N-PVR-MDF
e4
Xc
Media Delivery,
Functions
Xd
AOT
69
TU Berlin
RTSP protocol for media IPTV Service
Control
control: Broadcast
trick
SSF
Functions
modes, Content on DemandCoD-SCF
SDF
and Network
PVR
BC-SCF
IPTV Media
Control Functions
Ut
Xa
CoD-MCF
BC-MCF
Sh
N-PVR-MCF
Sh
IGMP protocol for
control of plain UPSF
BroadcastUETelevision
N-PVR-SCF
Xp
Application and
ISC IPTV Service
Functions
Cx
IPTV Media
Delivery Functions
y2
ISC
Gm
Core IMS
CoD-MDF
Gq'
e2
BC-MDF
NASS
RACS
N-PVR-MDF
e4
Transport Control
Functions
Transport Functions
Xc
Media Delivery,
RTP protocol for
media
transport
Functions
Xd
AOT
70
TU Berlin
IMS - Zusammenfassung
SIP als Standardsignalisierungsprotokoll im IMS
Ö
Ö
IMS bietet :
t neue IP basierte Dienste
t schnelle Dienstentwicklung („Layered“ Architektur)
t Interoperabilität der Dienste
t Zugriffsnetzwerkunabhängigkeit (UMTS, WLAN, DSL)
t AAA: Charging, single-sign-on, Sicherheit
t Roaming
t Neues Geschäftsmodel für den Netzwerk Betreiber
Ö
Aber:
t „IMS is complex and costly …“
t „little (if any) in the way of new applications“ ?
t „there are performance concerns“
(„IMS 101: What You Need To Know Now”, John Waclawsky)
t
IMS Erfolg ist abhängig von der Akzeptanz der Benutzer
t
AOT
Risiko: network operator als reine “bit pipe”, wenn Benutzer unabhängigie KommunkaitonsAnwendungen nutzt (z.B. P2P)
71
TU Berlin
Referenzen
Ö The Internet Engineering Task Force (IETF): http://www.ietf.org/
t RFCs SIP, Diameter
Ö The 3rd Generation Partnership Project (3GPP): http://www.3gpp.org/
Ö The Third Generation Partnership Project 2 (3GPP2): http://www.3ggp2.org/
Ö Parlay Group: http://www.parlay.org/en/index.asp
t OSA/Parlay, Parlay X
Ö Tech-Invite : http://www.tech-invite.com/ :
t Collection of SIP, ETSI, 3GPP, TISPAN, … standards
Ö The IMS Lantern Blog : http://theimslantern.blogspot.com/
t Overview current IMS deployments, IMS resources links
t Many IMS details & aspects
AOT
72
TU Berlin
Ende
AOT
73
TU Berlin
Backup
AOT
74
TU Berlin
Ö IMS
AOT
75
TU Berlin
IMS – Beispiel Service
Ö Service für
subscriber B : spiele
Ansage ab, wenn ich
bei eingehenden
Anruf nicht
erreichbar bin !
User B
online?
„Away“!
INVITE „play
announcment of
user B“
Presence server
INVITE
Charging
information
Trigger service
for user B
INVITE User B
RTP
audio
stream
User A
AOT
76
TU Berlin
IMS Main Features
IMS Phase 1 - 3GPP Rel5
9
9
9
9
9
9
9
9
SIP Session Control for IMS Signalling
Security & IMS Authentication :
9 SIP signalling integrity (IPSec : UE / P-CSCF)
9 IMS User/Service authentication (IMS-AKA)
QoS :
9 SBLP (Go : P-CSCF-PDF / GGSN-PEF)
9 SIP Compression (Sigcomp, UE/P-CSCF)
9 Header compression in RAN (UE / RNC, re-use
of RoHC)
Charging (mainly Offline) and OAM&P
Multimedia codecs
OSA support
CAMEL (Phase 4) for IM-SSF
IPv6 use for SIP signalling and IMS user traffic
9 IPv4 optional (guidelines & IPv6 evolution)
9
9
9
9
9
IMS Phase 2 - 3GPP Rel6
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
Inter-working with non-IMS IP networks (e.g. Internet)
Inter-working with CS networks (e.g. PSTN, CS PLMN)
IMS Services combining CS (rt) & PS (nrt) : CSI Phase 1
Access agnostic IMS specifications
UTRAN QoS optimisation for PS conversational services
WLAN/3GPP inter-working for using PS/IMS services
Presence/Instant Messaging (SIMPLE) → OMA
Group management & Conferencing (SIP)
Immediate and Session based messaging
Service enablers for IMS : PoC → OMA
Dynamic QoS policy (including Gq (P-CSCF/PDF))
Lawful interception
SIP forking
Full charging framework (incl. Online and Flow based)
IPv4 option & IPv6 evolution guidelines still applicable
IMS ‘Phase 3’ - 3GPP Rel7 (Draft contents, depends on Rel6 and company proposals)
Emergency services
IMS local services
Enhanced QoS (extension for IP Inter-working)
MRFP / MRFC (Mp) & ALG/Tr-GW (Ix) interfaces
GERAN optimisation for PS conversational services
9
9
9
IMS enhancements for Fixed Broadband access
Interim Security (IP based authentication)
Merging of Go and Gx (TPF/FBC) interfaces
Quelle: http://europe.eu.int/information_society/policy/ecomm/doc/info_centre/public_consult/ngn/comments/coureau.ppt
AOT
77
TU Berlin
AOT
78
TU Berlin
AOT
79
TU Berlin
SIP/IMS - Warum SIP ?
Ö
Simple.
t „SIP is based on a straightforward request-response interaction model, making life
simple and comprehensible for developers. The messages are also text-based which
makes them easy to parse, create, read, understand and debug.“
Ö
Extensible.
t „SIP can set up sessions for any media type, be it voice, video, application sharing or
teleportation (once we invent it!)“
Ö
Flexible.
t „SIP allows developers to interact with the individual protocol messages (within limits)
without breaking anything. This means that developers can perform a lot of neat tricks
that make development much easier.“
Ö
Familiar:
t „In large part because SIP borrows heavily from HTTP and other internet standards
from the IETF, lots of web-like technologies can be used to build SIP applications. SIP
development looks and feels a lot like web development, and there are a lot of web
developers out there.“
http://www.sipcenter.com/sip.nsf/html/IMS+IP+Multimedia+Subsystem
AOT
80
TU Berlin
IMS – Registration - Signaling Flow (1/2) (3GPP AKA)
Benutzer Authentification
+
Schlüsselaustausch für
die Verschlüsselung aller
weiteren SIP Nachrichten
zw. UE und P-CSCF
Quelle: Forschungszentrum Telekommunikation Wien, NGN Service Layer Security, Oliver Jung
AOT
81
TU Berlin
IMS – Registration - Signaling Flow (2/2) (3GPP AKA)
Quelle: Forschungszentrum Telekommunikation Wien, NGN Service Layer Security, Oliver Jung
AOT
82
TU Berlin
IMS – Session Initiation - Signaling Flow (1/3)
AOT
83
TU Berlin
AOT
84
TU Berlin
AOT
85
TU Berlin
IMS – Session Initiation - Zusammenfassung
•Reservierung der Media Resourcen notwendig
•Policy Decision Function (PDF) authorisiert QoS Resourcen
anhand policies
•(GPRS) Packet Data Protocol (PDP) Context activation
•vor der Reservierung muss session ausgehandelt sein (PRACK,
SIP early media negotiation)
•das alles sollte vor dem Klingeln geschehen (SIP „180 Ringing“)
AOT
86
TU Berlin
Diameter Protocol
Ö
Ö
Ö
Diameter:
t Request - Response Protocol, binary encoded, over reliable transport (e.g. TCP)
t Base Protocol (RFC 3588): Diameter sessions = exchange of commands and attribute value pairs
(AVPs) between authorized Diameter clients and servers
t extensible for other applications through addition of new commands and AVPs
3GPP specific Diameter application: Cx, Dx interfaces: TS 29.228, Sh interface: TS 29.329, Codecs,
identifiers: TS 29.230
Example commands : Server
Assignment Request and Answer
(SAR/SAA) bei SIP REGISTER
t S-CSCF -> HSS: „user is
registered!“, request user
profil information
t SAR AVPs: IMPI, IMPU, SCSCF, …
t SAA AVPs: IMPI, IMPU,
User Profil, Charging
Information (address of
charging function), …
Quelle: http://www-128.ibm.com/developerworks/library/wi-diameter/index.html
AOT
87
TU Berlin
AOT
88
TU Berlin
IMS – Sicherheitsaspekte (2)
Ö
Problem „early IMS“
t
„early IMS“ = IMS der ersten Phase: keine IP6 fähigen Geräte / keine
USIM/ISIM in den Endgeräten
t
3GPP definiert „early IMS“ Security
t
Aber: nur ausgelegt für GPRS, keine Lösung für WLAN / xDSL
Quelle : ETSI TS 33.203-710
AOT
89
TU Berlin
IMS – Charging Function - Offline Charging
Ö
Ö
Ö
Offline Charging : users pay for their
services periodically (e.g. at the end of
month)
BS
Charging Collection Function (CCF)
t collecting of Session charging
information from the IMS nodes
(by using Rf interface (Diameter))
t intermediate data storage
buffering; call detail records (CDR)
t transfer of the charging data to the
(operator’s chosen) billing
systems (BS)
SIP message extension headers:
t P-Charging-Vector, P-ChargingFunction-Address
t Inserted by P-CSCF and S-CSCF
t Identifies: session, PDP-context,
orginating / terminating network, CCF
address
AOT
Home(B)
Home(A)
CCF Rf
AAA
AS
AS
AS
AS
MRFC
MRFC
MRFC
MRFC
SS--CSCF
CSCF
S-CSCF
S-CSCF
II--CSCF
CSCF
I-CSCF
I-CSCF
PP--CSCF
CSCF
P-CSCF
P-CSCF
BGCF
BGCF
BGCF
BGCF
Rf
CCF
AAA
Visited(B)
Visited(A)
Rf
AAA
BS
Rf
PP--CSCF
CSCF
P-CSCF
P-CSCF
AAA
BS
BS
PDSN
PDSN
90
TU Berlin
IMS – Charging Function - Online Charging
Ö
Ö
Online Charging: Prepaid Service,
credit based charging
Session Charging Function (SCF) =
AS, erhält “blind” SIP requests über
User Profil Filterregeln
S-CSCF
t
t
t
Ö
Home(A) + Visited(A)
SCF meldet accounting
Informationen an
Correlation Function (CF)
(über Rb Diameter interface)
Wenn Benutzer Kredit
abgelaufen, Meldung von
CF an SCF,
SCF beendet session durch
SIP BYE an Teilnehmer
(agiert als B2BUA)
AS und MRFC melden Ereignisse
an Event Charing Function (ECF)
(aus SIP P-Charging-FunctionAddress header), ECF an CF
AOT
S-CSCF
ISC Session
Charging
Function
Rb
Correlation
Function
Account
Home(B) + Visited(B)
Bearer
Charging
Function
Bearer
Charging
Function
Correlation
Function
Account
Re
Rating
Function
Rc
ISC S-CSCF
S-CSCF
Rating
Function
Rc
Charging
information
flow
Ro
MRFC Ro
MRFC
Session
Charging
Function
Re
Re
AS(s)
AS(s)
Rb
Re
Event
Charging
Function
Event
Charging
Function
SCCF
SCCF
CPCF
CPCF
Ro AS(s)
AS(s)
Ro MRFC
MRFC
ITS
ITS
ITS
ITS
Online
CCF Charging System
Online Charging System
91
TU Berlin
DAI – Labor IMS Aktivitäten
AOT
92
TU Berlin
Ö NGN
AOT
93
TU Berlin
The role of SBCs in IMS and
TISPAN based networks
http://www.newport-networks.com/downloads/DaveGladwinSBCsAndIMS.pdf
AOT
94
TU Berlin
IMS – NGN IMS Residential Gateway
AOT
95
TU Berlin
IMS - NGN Integration
Quelle: Alcatel, „Quality of Service for IMS on Fixed Networks“
AOT
96
TU Berlin
IMS – NGN Integration (2)
Network Attachment Subsystem (NASS):
Location Management, provisioning of IP addresses, IP
authentication, authorization of network access
Resource Admission Control Subsystem (RACS):
controls QoS resources, policies, NAT traversal, IPv4/IPv6
Protocol Translation, Security
Quelle: http://www.itu.int/ITU-T/worksem/h325/200605/presentations/s1p4-brennan.pdf
AOT
97
TU Berlin
AOT
98
TU Berlin
Ö SIP
AOT
99
TU Berlin
SIP - Session establishment (4)
Proxy 1 und Proxy 2
sind im signaling path
der session durch
Record-Routing
redirect server (vs. proxy
server):
kein Weiterleiten der
requests, bestimmt UAS
location aus database und
sendet sie in 3xx class
response zurück
AOT
100
TU Berlin
SIP Erweiterungen –
Erweiterungen für Session Kontrolle
Ö PRACK Methode :
t bestätigt Erhalt der 1xx responses zum
INVITE request (werden nun wie das 200
OK retransmitted, bis PRACK eintrifft)
t Eingeführt zur PSTN Kompatibilität
t Benutzt zum Aushandeln von „early
media“, SDP offer/answer werden schon
in INVITE / 1xx / PRACK ausgetauscht
Ö UPDATE Methode : Neuaushandlung wie reINVITE für „early media“
Ö INFO Methode : Session relevante
Informationen (Applikations-Ebene), z.B.
„the user is currently typing something“
AOT
101
TU Berlin
SIP - Transaction and Dialogs
RFC 3261 : Protokoll Realisierung in verschiedenen
logischen Ebenen – encoding, transport,
transaction, transaction user (TU)
Ö
Ö
Transaction: umfasst request und alle responses
t transaction layer verarbeitet retransmissions,
message Zuordnung und request timeouts
t Zuordnung durch transaction identifier =
branch parameter im Via header
Via: SIP/2.0/UDP 192.168.1.2:15890;
branch=z9hG4bK71d20bccbea3e3c145dc60466c44fb42
Ö
Dialog: Sequenz von transactions
t Peer-to-peer Verbindung zw. zwei UAs über
eine bestimmte Zeit
t Vereinfachung des Routens, direkte
Kommunikation
t UA location vermittelt im Contact Header in
request und response
AOT
Quelle: „SIP Introduction“, J. Janak.
102
TU Berlin
SIP Erweiterungen – Event Notification (1)
ÖEnd-to-end notification (links) vs. zentraler Ansatz (rechts) mit PUBLISH und Event
State Compositor (ESC) / Event Publishing Agents (EPA):
AOT
103
TU Berlin

IP Multimedia Subsytem (IMS) - AOT

Transcrição

Documentos relacionados

Wir bieten mehr!

BT Wholesale VoIP

Central-Hotel Kaiserhof Hannover- Ernst-August-Platz 4

Freigabe des Releases 6

Ihre Premium Praxisanalyse - Installationsanleitung

Berater-Profil 3208 - R+K Unternehmensberatung

Kompass 2014 lesen - Rudolf Steiner Schulen der Schweiz

CA File Master™ Plus for IMS r8.5

Allgemeine Geschäftsbedingungen

Telekom All-IP Anschaltung