Presence Informationen und erweiterte Presence Funktionen im Speziellen XCAP und RLS

Inhaltsverzeichnis

1. Einleitung

2. SIP Event Framework
2.1. SUBSCRIBE
2.2. NOTIFY

3. Das Data Model für Presence und Instant Messaging
3.1. Überblick
3.2. Definitionen
3.3. Strukturaufbau
3.3.1. Person
3.3.2. Service
3.3.3. Device

4. Presence Information Data Format
4.1. Allgemeines
4.2. Das Data Model für Presence und PIDF
4.3. Elemente eines Presence Information Data Formates
4.3.1. Der XML Namespace für Presence Informationen
4.3.2. Das Presence Element
4.3.3. Das Tuple Element
4.3.4. Das Status Element
4.3.5. Status Erweiterungen
4.3.6. Das Contact Element
4.3.7. Das Note Element
4.3.8. Das Timestamp Element
4.3.9. URN Sub-Namespace Registration und XML Schema

5. Presence Architekturen

6. Das Presence Event Package
6.1. Definitionen
6.2. Ablauf
6.2.1. Lebensdauer einer Presence Subscription
6.2.2. Register
6.2.3. Die Presence URI
6.2.4. Authentifizierung und Autorisierung
6.2.5. Forking Request

7. Rich Presence Extension für das Presence Information Data Format (RPID)
7.1. Allgemeines
7.2. Aufbau
7.3. Elemente eines RPID Dokumentes
7.3.1. Das Activities Element
7.3.2. Das Mood Element
7.3.3. Das Place-is Element
7.3.4. Das Place-type Element
7.3.5. Das Privacy Element
7.3.6. Das Relationship Element
7.3.7. Das Service Class Element
7.3.8. Das Sphere Element
7.3.9. Das Status-Icon Element
7.3.10. Das Time Offset Element
7.3.11. User-Input Element
7.3.12. Beispiel eines RPID Dokumentes

8. Das Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
8.1. Einführung in XCAP
8.2. Extensible Markup Language (XML)
8.2.1. Allgemeiner Überblick
8.2.2. Aufbau eines XML Dokumentes
8.2.3. Namespace (Namensraum)
8.3. Einsatzbereiche XCAP
8.3.1. Presence Rules
8.3.2. Presence Listen
8.4. Definitionen
8.5. XCAP Aufbau
8.5.1. XCAP Root
8.5.2. Document Selector
8.5.3. Node Selector
8.6. XCAP Basis Operationen
8.7. Client Operationen
8.7.1. Abrufen eines Dokumentes
8.7.2. Erstellen oder Ersetzten eines Dokumentes
8.7.3. Löschen eines Dokumentes
8.7.4. Abrufen eines Elementes
8.7.5. Erstellen oder Ersetzten eines Elementes
8.7.6. Löschen eines Elementes
8.7.7. Abrufen, Erstellen, Ersetzten und Löschen eines Attributes
8.8. Erweiterte XCAP Operationen und Bedingungen
8.9. XCAP-Diff
8.9.1. XCAP-Diff SIP Eventpackage
8.9.2. XCAP-Diff Dokumente
8.10. Serververhalten und Fehlerbehandlung

9. Resource Lists
9.1. Überblick
9.2. Definitionen
9.3. Ablauf
9.4. Aufbau einer Resource List
9.5. Beispiel eine List Subscription

10. Praktische Durchführung
10.1. Testumgebung und Plattform
10.2. Installationsquellen des SIP Express Routers (SER)
10.3. Voraussetzungen bei Verwendung von Linux
10.4. Installation des SER
10.5. Einrichten der MySQL Datenbank
10.6. Einrichten des Webservers Apache und PhpMyAdmin
10.7. Konfiguration SER
10.8. Modulkonfiguration und –beschreibung
10.8.1. Das XCAP Module
10.8.2. Das PA Module
10.9. Praktische Anwendungsmöglichkeiten
10.9.1. Watcher Information and Presence
10.9.2. Resource Lists

11. Ausblicke und Zusammenfassung

A. Abbildungsverzeichniss

B. Tabellenverzeichniss

C. Abkürzungen

D. Literaturverzeichniss

E. Anhang
E.1 XML Schema für XCAP Konflikte und Error Handling
E.2 XML Schema für XCAP Server Capabililties
E.3 XML Schema für XCAP Diff Dokumente
E.4 XML Schema für Resource List Service in einem multipart /related Body Teil eines RMLI Dokumentes
E.5 RPID konformen Presence Informationen

1. Einleitung

Heutzutage besitzen die meisten Menschen eine Vielzahl von Kommunikationswege um jederzeit und überall für andere Teilnehmer erreichbar zu sein. Das Hauptproblem liegt jedoch darin, wie man seinen gewünschten Gesprächspartner zu einem bestimmten Zeitpunkt erreichen kann. Das nachfolgende Beispiel soll diesen täglich gewohnten Sachverhalt darstellen. Ein Teilnehmer wird in der Regel tagsüber versuchen einen anderen Teilnehmer über das normale PSTN Netz unter seiner Telefonnummer auf seinem Arbeitsplatz zu erreichen. Befindet sich der Gesprächspartner jedoch zu diesem Zeitpunkt gerade in einem Meeting, wird man üblicherweise an dessen Mailbox oder Stellvertreter bzw. an das Sekretariat weitergeleitet. In einem zweiten Schritt wird man das Anliegen in Form einer E-Mail verfassen und an dessen E-Mail Adresse versenden. Der gewünschte Kommunikationspartner verlässt jedoch nach dem Meeting sein Büro und begibt sich auf eine Geschäftsreise mit dem Auto. Nach einiger Zeit versucht man den Teilnehmer unter einer seiner Mobilnummern zu erreichen. Zunächst wird man versuchen den Gesprächspartner unter seiner vom Arbeitgeber zur Verfügung gestellten Mobilnummer zu erreichen. Weil er das Gespräch während der Autofahrt nicht annimmt, wird man es unter seinem privaten Mobilanschluss probieren und da es sich in diesem Beispiel um einen dringenden Informationsaustausch handelt, versucht man diesen Vorgang abends nochmals. Zu diesem Zeitpunkt aber ist der gewünschte Gesprächspartner in einem Restaurant und möchte nicht gestört werden. Weitere Kommunikationswege wie z.B. SMS oder Instant Messaging Services könnten ebenfalls noch benützt werden. Schließlich meldet sich der Teilnehmer nach dem Essen bei seinem Gesprächspartner, wobei in der Zwischenzeit ein ganzer Tag verging, bis man endlich zu einem erfolgreichen Verbindungsaufbau gelangt ist.

Hauptursache für die vergeblichen Versuche den Gesprächspartner zu erreichen liegt in diesem Beispiel darin, dass man keine Presence Informationen und die damit verbundene Erreichbarkeit des Anderen besitzt. Unter Verwendung einer eindeutigen SIP URI können mehrere Endgeräte einem Benutzerprofil zugeordnet werden und somit besitzt man die Möglichkeit entweder automatisiert über Kalendereinträge aus anderen Anwendungen oder manuell seine Erreichbarkeit anderen Teilnehmern zu signalisieren. Unter Verwendung des SIP spezifischen Event Frameworks kann ein Benutzer somit entscheiden, welchen Teil der Presence Information dieser einem bestimmten anderen Teilnehmer oder Gruppe mitteilen möchte. Das hierfür verwendete Protokoll lautet XCAP, welches ermöglicht gezielt Informationen in Form von XML Dokumenten zu manipulieren und nur jene Teilnehmer über die Presence Informationen zu informieren, welche man in seiner Buddy Liste als wünschenswert erachtet. XCAP ermöglicht es zudem nicht nur den Status der Verfügbarkeit zu manipulieren, sondern auch zusätzlich weitere Informationen wie Aufenthaltsort oder Gemütszustände etc. anderen Teilnehmern mitzuteilen.

Im Rahmen dieser Diplomarbeit wird versucht das Zusammenspiel zwischen den einzelnen Netzteilnehmern auf Basis des SUBSCRIBE und NOTIFY Prinzips darzustellen, und es wird eine Möglichkeit aufgezeigt um an Presence Informationen zu gelangen. Damit ein Watcher nicht permanent SUBSCRIBE Request an die unterschiedlichsten Quellen aussenden muss, um an den aktuellen Status von Presence Information zu gelangen, werden des weiteren Presence Lists definiert, welche auf einem Resource List Server abgelegt sind und es einem Teilnehmer erlauben nur die entsprechenden Änderungen abrufen zu müssen. Diese Arbeit stützt sich ausschließlich auf die von der Internet Engineering Task Force (IETF) publizierten RFC (Request for Comments), welche in dem Literaturverzeichnis aufgelistet sind.

Ziel des theoretischen Teiles ist es das verstreute Wissen zahlreicher Standards in einer Arbeit zu vereinigen und dementsprechend zu interpretieren. Die praktische Analyse setzt sich mit dem offenen und für den nicht kommerziellen Bereich frei verfügbaren SIP Express Routers von iptel.org auseinander und stellt die Installation sowie die Konfiguration eines kompletten Presence XCAP und Resource List Servers vor. Neben den technischen Spezifikationen werden zusätzlich die grundlegendsten Presence Funktionen in Bezug auf Watcher Information (Winfo) und Resource Lists erläutert.

2. SIP Event Framework

Grundlage des im RFC 3265 definierten SIP spezifischen Event Frameworks ist die benutzerspezifische Ereignismitteilung eines beliebigen SIP Netzwerkelementes an einen User Agent. Diese funktionale Erweiterung des Standards ermöglicht mit den Methoden SUBSCRIBE und NOTIFY einem User Agent von einem entfernen Netzteilnehmer Benachrichtigungen zu verlangen wenn ein bestimmtes Ereignis eintritt. Der Client wird daher auch als Subscriber und die betreffende Resource als Notifier bezeichnet.

2.1. SUBSCRIBE

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.Basis SIP Event Presence Subscription

1. Abbildung 1 gezeigt, sendet der User Agent A eine SUBSCRIBE Nachricht an den Teilnehmer B aus, um Informationen über seinen Presence Status zu erlangen. Hierzu verwendet dieser im Header Teil der SIP Message die Methode SUBSCRIBE mit dem Event presence als Argument. Der SIP Header expires definiert hierbei die Lebensdauer der Registrierung, welche in Sekunden angegeben wird. Nach Ablauf dieser Zeitspanne muss mittels eines neuen SUBSCRIBE die Dauer der Überwachung verlängert werden.

Abbildung in dieser Leseprobe nicht enthalten

2. Ist der User Agent B online, willig und auch in der Lage seine Anwesenheit zu übermitteln, bestätigt dieser zunächst einmal den Erhalt der SUBSCRIBE Nachricht mittels Aussenden einer Statusinformation der Gruppe 2xx. Der Status-Code ist eine dreistellige Nummer, die dem Ergebnis der Transaktion entspricht. Status-Codes sind wie in Tabelle 1 dargestellt in sechs Klassen eingeteilt (1xx, 2xx ... 6xx).

Abbildung in dieser Leseprobe nicht enthalten

3. Anschließend sendet User Agent B ein NOTIFY, welches im SIP Header Subscription State als Argument pending beinhaltet.

Abbildung in dieser Leseprobe nicht enthalten

4. Erst nachdem User Agent A mittels eines 200 OK Responses den Erhalt des ersten NOTIFY bestätigt, sendet User Agent B die gewünschte Presence Information über seinen Online Status.

Abbildung in dieser Leseprobe nicht enthalten

5. Wie beim ersten NOTIFY enthält auch diese Nachricht im SIP Header Teil den Eintrag Subscription State, diesmal jedoch mit dem Argument active. Zusätzlich wird im Message Body XML Code übertragen, der näheren Aufschluss über den Status einer Presence ermöglicht.

Abbildung in dieser Leseprobe nicht enthalten

6. Schließlich wird der Erhalt des NOTIFY vom User Agent A, welcher ursprünglich eine Anfrage zur Überwachung des Online-Status an User Agent B gestellt hat mittels eines 200 OK bestätigt.

Abbildung in dieser Leseprobe nicht enthalten

User Agent B überträgt nun solange jede Veränderung seiner Presence Information mittels NOTIFY an User Agent A, solange dieser den expire Wert im SIP Header nicht auf Null setzt und somit die Subscription aktiv bleibt. Ebenso kann User Agent B die Überwachung beenden, indem er ein NOTIFY an User Agent A sendet, welches im SIP Header Subscription State als Argument den Wert terminated beinhaltet. Zusätzlich kann der Notifier in einem Response die Zeitdauer der Subscription verkürzen, wobei eine Verlängerung jedoch nicht möglich ist. Eine Subscription erfordert in der Regel eine entsprechende Autorisierung durch den Notifier.

Die Autorisierung erfolgt normalerweise nicht automatisch, sondern erst durch die manuelle Bestätigung durch den Inhaber der Resource. Daher wird ein SUBSCRIBE Request oft nicht sofort durch einen 200 OK Response beantwortet, sondern zunächst durch einen 202 Accepted. Dies bedeutet soviel, dass der User Agent bzw. Server bestätigt die Nachricht verstanden zu haben.

Wenn innerhalb eines Dialoges ein erneutes SUBSCRIBE gesendet wird und dieses mittels 481 Response Dialog Does Not Exist beantwortet wird, bedeutet das, dass der entsprechende Server die Subscription bereits terminiert hat. Der User Agent muss daher mit erneutem Aussenden eines SUBSCRIBE einen neuen Dialog eröffnen.

Die Methoden SUBSCRIBE und NOTIFY sind jeweils nur in eine Richtung möglich und daher gegenläufig. Das bedeutet, dass ein SUBSCRIBE nur vom Subscriber zum Notifier möglich ist und umgekehrt. Dies schließt natürlich nicht aus, dass ein und derselbe User Agent zur selben Zeit sowohl die Rolle eines Subscriber als auch Notifier übernehmen kann. Ein NOTIFY Request wird generell nur innerhalb eines durch SUBSCRIBE definierten Dialoges gesendet. Da die Assoziation zwischen Subscriber und Notifier in der Regel länger andauert und mehrere Transaktionen umfasst, erzeugt somit eine Event-Subscription automatisch einen SIP Dialog.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Response Codes

Pflichtfelder im Header Teil eines SUBSCRIBE:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2 : Pflichtfelder innerhalb eines SUBSCRIBE

2.2. NOTIFY

Ein NOTIFY wird immer innerhalb eines Dialoges gesendet, sofern eine Subscription zwischen dem Subscriber und dem Notifier besteht und dient dem User Agent dazu, Information über den Eintritt eines bestimmten Ereignisses zu übermitteln. Eine Subscription kann jedoch auch ohne Aussenden eines SUBSCRIBE erfolgen, indem eine anderer SIP Request gesendet wird wie z.B. REFER. Zusätzlich zu den innerhalb eines SUBSCRIBE vorhandene Header kommt bei NOTIFY noch das Subscription-State Header Field dazu, welches Auskunft über den aktuellen Zustand der Subscription gibt und die Ereignis-Information im Message Body Teil.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3 : Inhalt des Subscription-State Header Fields

Wenn das Event-Package auch Delta-Informationen zulässt, dann enthält die Ereignisinformation im NOTIFY-Body auch eine fortlaufende Versionsnummer. Diese „State Version Number“ wird beim Aussenden jedes NOTIFY inkrementiert und ermöglicht somit verloren gegangene NOTIFYs zu erkennen.

Das SIP-Event-Framework definiert nur den prinzipiellen Ablauf von SUBSCRIBE und NOTIFY. Jeder Anwender dieses Mechanismus muss in einer separaten Spezifikation (Event Package) die Details der jeweils zu meldenden Ereignisse festlegen.

Ein Event Package enthält unter anderem:

- Name des Event Package
- Bezeichnung und Beschreibung der Events
- Message Body von SUBSCRIBE und NOTIFY
- Zulässigkeit von Delta-Information im NOTIFY
- Maximal zulässige Ereignisrate, Filter-Möglichkeiten
- Default-Wert der Subscription-Dauer

Der entsprechende Server liest aus dem Allow-Event Header Field aus, welche Packages unterstützt werden.

Das Event-Package ist ein spezieller Typ eines Packages, in welchem Spezifikationen über den Status Zustand eines Notifier definiert sind, die an einen Subscriber übermittelt werden. Das Event Template Package hingegen ist ein spezieller Typ des Event Packages, welches eine Reihe von Stati definiert, die auf alle möglichen Event Packages angewendet werden können. Ein Template Packages kann auch auf ein Package angewendet werden, indem diese durch ein „.“ getrennt werden. Z.B. ermöglicht das presence.winfo Packages die Anwendung des Watcher Info Template Packages auf das Presence Packages.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4 : Auszug aus einigen Event-Packages

3. Das Data Model für Presence und Instant Messaging

Das Modell für Presence stützt sich im Folgenden hauptsächlich auf die beiden Rfc 2778 : „ A Model for Presence and Instant Messaging,“ von M. Day, J. Rosenberg, H. Sugano sowie RFC 4479: “ A Data Model for Presence,“ von J. Rosenberg.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Das Presence Data Modell

Presence wird im Rahmen des Standards [2] als die Fähigkeit, Bereitschaft und Wunsch zur Kommunikation über eine Anzahl von Devices bezeichnet.

3.1. Überblick

Ein Presence und Instant Messaging System ermöglicht es Teilnehmern, sich bei anderen Usern zu subskribieren und gleichzeitig Notifications über deren Status zu erfahren sowie Textmeldungen auszutauschen. In diesem Modell werden 2 Services gelistet: Das Presence Service und das Instant Messaging Service. Ein Presence Service erhält Informationen, speichert diese und verteilt Sie in Form von Presence Information. Ein Instant Messaging Service hingegen erhält Instant Messages und stellt diese an Instant Inboxen zu.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 : Überblick Presence Service

3.2. Definitionen

- Presentity: Eine Presentity speichert und verteilt Presence Informationen und ist eine Kombination aus Person, Service und Device, welche gemeinsam den Presence Status eines Teilnehmers darstellen.
- Watcher: Er empfängt Presence Informationen von einem Presence Service oder einem anderen Watcher.
- Presentity URI: Eine bestimmte URI die den Presence Status eines Teilnehmers eindeutig identifiziert.
- Presence Agent: Auch als Notifier bezeichnet, stellt Presence Informationen für eine Resource zur Verfügung.
- Presence User Agent: Auch als Publisher bezeichnet, repräsentiert ein Service oder auch eine Software welche Informationen über den aktuellen Status einer Presence Information für eine bestimmte Presentity besitzt. Sinngemäß kann ein Presence Agent auch die Funktion eines Presence User Agent übernehmen.

Für jede eindeutige Presentity im Netzwerk existieren eine oder mehrere Presentity URIs. Der Grund dafür liegt in der Tatsache, dass eine Presentity durch eine URI aus dem Presence Schema [5] und zusätzlich durch die Protokoll spezifische URI (SIP URI oder Extensible Messaging and Presence Protocol Internationalized Resource Indentifier (XMPP IRI) [6] ) festgelegt wird. In der Regel handelt es sich bei der Presentity URI natürlich um die Request URI, welche durch den SIP SUBSCRIBE Request repräsentiert wird, also die Address of Record.

3.3. Strukturaufbau

Watcher werden einerseits unterteilt in Subscriber und Fetcher bzw. Poller auf der anderen Seite. Subscriber werden von einem Presence Service über NOTIFY jederzeit über Änderungen der Presence Information über ein oder mehrere Presentities verständigt.

Ein Fetcher ruft Presence Information über ein oder mehrere Presentities ab, ohne jedoch eine Subscription angefordert zu haben. Ein Presence Service enthält und verteilt zusätzlich Watcher Informationen über die Watcher und deren Aktivitäten.

Ein Instant Message Service besteht ebenso aus 2 Clientkomponenten. Der Sender stellt Instant Messages dem Service für die weitere Zustellung zur Verfügung. Jede Nachricht wird durch das Instant Message Service an eine bestimmte Instant Inbox adressiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Überblick Instant Message Service

Presence Information wie in Abbildung 6 dargestellt besteht dem Modell gemäß aus einer beliebigen Anzahl von Elementen auch als Presence Tuples bezeichnet. Jedes Element besteht aus einer Kennzeichnung für den Status, z.B. online, offline, busy, do not disturb, etc., und optional aus einer Adresse und anderen Presence Eigenschaften. Die Adresse gibt Auskunft über die Art der Kommunikation (z.B. Instant Message Service) und beinhaltet zusätzlich die Contact Address (z.B. Instant Inbox Address). Dem Standard gemäß muss ein Presence System über mindestens 2 Stati verfügen, OPEN und CLOSED, wobei jeder dieser Stati näher beschrieben werden kann (OPEN kann auf dem Status available oder open for private etc. gemappt werden). Da es sich bei den Teilnehmern außerhalb des Models um Personen, Gruppen oder aber auch Software handelt, definiert das Modell diese als Principals. Ein Principal kommuniziert mit dem System über verschiedene User Agents (Inbox User Agent, Sender User Agent, Presence User Agent oder Watcher User Agent).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 : Presence und Instant Messaging System

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 : Struktur der Presence Information

3.3.1. Person

Die Komponente Personen innerhalb des Models stellt Informationen über einen Teilnehmer dar, über welchen Presence Angaben beschrieben werden sollen. Diese Informationen bestehen aus Merkmalen eines Users sowie aus seinem Presence Status. Die Merkmale eines Teilnehmers sind statische Bestandteile, welche sich unter normalen Umständen nicht ändern, wie z.B. Alter, Geschlecht oder Geburtstag. Ein anders Merkmal kann aber auch der Alias darstellen. Ein Alias stellt eine URI dar, welche ein und denselben User identifiziert, jedoch mit einer anderen Presentity URI. Z.B. wird die Presentity von Bob als URI sip:bob@example.com in einem Presence Dokument dargestellt und verweist auf die Alias sip:robert@example.com und sip:robert.enderle@example.com. Status Informationen stellen den dynamischen Informationsteil eines Users dar. Dynamische Status Informationen geben Angaben über den Aufenthaltsort, den Gemütszustand oder welcher Aktivität ein Teilnehmer gerade nachgeht. Das Modell geht davon aus, dass immer nur eine Personen Komponente pro Presentity existiert. Das bedeutet jedoch auch, dass das Modell nicht zwischen einer Person, Gruppe von Teilnehmern oder einer nicht existierenden Person unterscheiden kann. Ein Presence Dokument könnte z.B. den Status eines Help Desks beschreiben. Sind sämtliche Support Mitarbeiter nicht verfügbar, würde die Personen Komponente auf „nicht verfügbar“ oder „in einer Besprechung“ gesetzt werden. Für einen Watcher würde demnach nicht ersichtbar sein, ob es sich bei diesem Presence Dokument um eine Einzelperson oder eine gesamte Gruppe handelt.

3.3.2. Service

Jede Presentity hat Zugang zu einer Vielfalt von Services, z.B. Telefonie, Push-to-Talk, Instant Messaging, Short Message Service oder Multimedia Message Service. Im Prinzip stellt jede Software oder jeder Hardware Agent ein Service dar. Das bedeutet, sobald eine Person eine Software Applikation wie z.B. Eyebeam startet, dieser Vorgang ein Service darstellt. Jedes Service beinhaltet bestimmte Eigenschaften, welche die Möglichkeiten und die Bestimmung dieses Services beschreiben. Ein Service kann z.B. zuständig sein um die Übertragsart zwischen zwei Devices auszuhandeln, welche Kommunikationsrichtung zulässig ist, oder welche SIP Extensions unterstützt werden. Im Gegensatz dazu steht der Zweck des Services, z.B. Anrufbeantworterfunktion oder Voicemail-Server. Ziel des Modells ist es dem Watcher innerhalb eines Presence Dokumentes die Auswahl zu überlassen, aus einer Vielzahl von Services selektieren zu können.

3.3.3. Device

Devices stellen den physikalischen Teil der Umgebung dar, in welchem ein oder mehrere Services z.B. Soft- oder Hardware Clients ausgeführt werden. Ein einziges Service kann in einem oder mehreren Devices ausgeführt werden. Das bedeutet, dass mehrere SIP-Phones sich bei einer Address of Record (AoR) registrieren können, welche genau ein oder mehrere Services zur Verfügung stellt. Das bedeutet daher, dass ein Service zwei verschiedenen Endgeräten zugewiesen werden kann. Devices werden mittels Device ID dargestellt. In der Regel ist die Device ID die URN. Die URN ist eindeutig und einzigartig und wird in der Regel als Mac-Adresse bestimmt. Bei POSTS wird hierfür die Electronic Serial Number (ESN) genützt. Derzeit werden beide Verfahren vom URI Schema nicht unterstützt und daher vorübergehend die Universally Unique Identifier (UUID) URN [1] genutzt. Für Devices mit vorhandener Mac-Adresse wird Version 1 UUIDs empfohlen, für jene ohne Mac-Adresse die Version 4 UUID.

4. Presence Information Data Format

4.1. Allgemeines

Das Presence Information Data Format (PIDF) [7] dient dazu Presence Data darzustellen und einem Teilnehmer die Möglichkeit zu geben, unter verschiedenen Services das jenes auszuwählen um die korrekte Kommunikation mit anderen Usern aufbauen zu können.

PIDF ermöglicht es, Presence Informationen gemäß dem Common Profiles for Instant Messaging (CPIM) und Presence (CPP) zwischen mehren Teilnehmern austauschen zu können. Presence Information besteht aus ein oder mehreren Presence Tuples. Jedes Tuple wiederum beinhaltet einen Status eine optionale Contact Address (URI) und weitere optionale Presence Anmerkungen. PIDF Dokumente sind im Extensible Markup Language (XML) codiert. Ein PIDF Objekt muss daher eine XML Deklaration besitzen und sollte eine Kodierung der Deklaration aufweisen, z.B. <?xml version=’1.0’ encoding=’UTF-8’?>

4.2. Das Data Model für Presence und PIDF

Weil das PIDF zum Zeitpunk der Einführung des Data Models für Presence bereits existierte, war es notwendig eine Zuweisung zwischen den beiden Standards zu finden. Um dies zu erreichen werden die vorhandenen XML Elemente des PIDF gemäß dem Data Model für Presence weiter verwendet und durch einheitlich definierte Erweiterungen ergänzt. Wie in Abbildung 7 dargestellt, werden neue Elemente in das vorhandene PIDF Format in Form von Extensions eingebunden. Das Root Element des neuen Data Models besteht aus einem entity Attribut, welches gemäß dem Standard eine Presentity URI darstellt. Das < tuple > Element wird für die Beschreibung des jeweiligen Presence Service verwendet, während das Child Element < status > den dynamischen Teil und damit die Eigenschaften des Services darstellt. Das < contact > Element schließlich beinhaltet die Service URI. Um die statische Service Information ablegen zu können, wird eine neues <ext n> Element eingefügt. Ebenso werden die beiden neuen Elemente <person> und <device> definiert um somit die personen-und gerätespezifischen Daten definieren zu können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Zuweisung PIDF zu Presence Data Model

4.3. Elemente eines Presence Information Data Formates

4.3.1. Der XML Namespace für Presence Informationen

PIDF Elemente sind dem XML Namespace Namen in der Form urn:ietf:params:xml:ns:pidf zugewiesen. Als Namespace URIs verwendet der Standard eine URN, wobei der Namespace Identifier ietf lautet. Nachfolgendes Beispiel zeigt den Code eines XML Namespaces.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5 : Der URN Namespace

Jeder Namespace wird durch eine eindeutige URI identifiziert, wobei die URI als Globally Unique Indentifier verwendet wird. Der Standard ermöglicht es jedoch auch Entwicklern neue Elemente dem PIDF Dokument hinzuzufügen, wobei um Konflikte zu vermeiden, ein anderslautender Namespace URI zu verwenden ist. Die allgemeine Form eines Namespace lautet: <prefix:element-name...>.</prefix:element-name> wobei ebenfalls ein Default Namespace für XML Elemente verwendet werden kann ohne einen Prefix angeben zu müssen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6: Der Default Namespace

4.3.2. Das Presence Element

Die Wurzel eines application/pidf+xml Objektes ist immer das Element < presence > mit dem zugehörigen Presence Information Namespace. Das < presence > Element muss ein entity Attribut besitzen. Das entity Attribut gibt die URI des Teilnehmers oder besser gesagt die Presentity, welche das PIDF publizieren möchte an. Zusätzlich muss das < presence > Element auch eine Namespace Deklaration (xmls) in der Form urn:ietf:params:xml:ns:pidf besitzen.

4.3.3. Das Tuple Element

Es stellt eine Presence Tuple dar, welches aus einem verpflichtendem < status > Element besteht, an welches sich anschließend optionale Extension Elemente anschließen können, welche auch von anderen Namespaces abgeleitet sein können. Weiters beinhaltet jede Tuple ein optionales <contact> Element sowie optimale < note > und < timestamp > Elemente. Jedes Tuple muss ein entsprechendes eindeutiges id Attribut in Form eines String beinhalten, um diese Tuple von anderen innerhalb desselben Namespace unterscheiden zu können. Die ID wird von Services oder Applikationen verwendet um das entsprechende Tuple eindeutig identifizieren zu können, da ein entsprechender Server ja mehrere Versionen ein und derselben Presentity eines PIDF Dokumentes speichern kann. Tuples ermöglichen es ein PIDF Dokument sinngemäß zu gliedern bzw. zu segmentieren. Es ist daher sinnvoll die gesamte Presence Information einer Presentity, welche aus mehreren Devices oder Applikationen stammen kann, aus Performance Gründen systematisch in Tuples zu gliedern.

4.3.4. Das Status Element

Das < status > Element besteht aus einem optionalen < basic > Element, an welches sich anschließend eine beliebige Anzahl von Extension Elementen anfügen können. Mehrere Status Werte innerhalb eines einzigen < tuple > Elementes sind zulässig. Dadurch ist es möglich eine genauere Beschreibung in Form von Aufenthaltsort oder Erreichbarkeit des Teilnehmers zu liefern. Es besteht jedoch auch die Möglichkeit, dass innerhalb eines PIDF Objektes der Wert innerhalb eines Tuple auf < basic > Open und eine anders Tuple den Status auf < basic > Closed gesetzt ist, was jedoch unweigerlich zu einem Konflikt führen muss. Nachfolgendes Beispiel zeigt ein PIDF Dokument mit dem < status > Element Open.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 7 : Beispiel eines PIDF Dokumentes

Das < basic > Element Open bedeutet z.B. in Bezug auf ein Instant Messaging Service, dass die dem < contact > Element zugeteilte Instant Inbox bereits ist Instant Messages zu empfangen und dementsprechend bei Closed nicht erreicht werden kann.

4.3.5. Status Erweiterungen

Erweiterungen zu dem Standard urn:ietf:params:xml:ns:pidf:status ermöglichen es Extensions für das < location > Element zu definieren, welche Attribute wie z.B. Home, Office oder Car beinhalten können.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 8 : PIDF Dokument mit Location Elementen

4.3.6. Das Contact Element

Das < contact > Element beinhaltet die URI der entsprechenden Contact Address.

Es beinhaltet zusätzlich ein optionales priority Attribut, welches eine Art Priorisierung zwischen den unterschiedlichen Contact Addresses ermöglicht. Der Wert des Attributes muss in dezimaler Form zwischen 0 und 1 liegen, z.B. 0; 0,28; 0,528 und darf aus maximal 3 nachfolgenden Kommastellen bestehen. Höhere Werte bedeuten demnach eine höhere Priorisierung der Contact Address. Werte die außerhalb des Bereiches liegen werden dementsprechend von der Applikation verworfen und behandelt als wäre dieser Wert nicht gesetzt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 9 : Das Contact Element

4.3.7. Das Note Element

Das < note > Element ermöglicht es Teilnehmern individuelle Anmerkungen zum jeweiligen Presence Status in Form eines String zu setzten. Das < note > Element kann sowohl als Child Element von < presence > als auch als Child Element des < tuple > Elementes im PIDF Dokument eingegliedert werden. Jedes < note > Element sollte als spezielles Attribut die Sprache des jeweiligen Teilnehmers repräsentieren. Dies wird in Form von xml:lang angegeben. Werte des Language Identifier [9] werden in RFC 3066 näher beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 10 : Das Note Element

4.3.8. Das Timestamp Element

Das < timestamp > Element wird als String dargestellt und gibt Auskunft über das Datum und den Zeitpunkt der Änderungen des jeweiligen Tuples. Werte dieses Attributes müssen dem Standard des IMPP Formates [11] gemäß RFC 3339 entsprechen. Aus Sicherheitsgründen sollte jedoch dieser Wert in allen Tuples vorhanden sein.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 11 : Das Timestamp Element

4.3.9. URN Sub-Namespace Registration und XML Schema

Nachfolgende Beispiele stellen zusammenfassend den XML Namespace URI für XML Elemente gemäß RFC 3863 für Presence Information im application/pidf+xml Format dar.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 12: Das XML Schema für XML Dokumente

Gemäß RFC 4479 wird das XML Schema für Presence Information in 2 Teile untergliedert. Das allgemeines Schema, common-schema.xsd,welches den allgemeinen Inhalt und die entsprechenden Definitionen beinhalten und den verbleibenden Anteil des Data Models, data-model.xsd.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 13: Das XML Schema in zweiteiliger Struktur

5. Presence Architekturen

Die Presence Architekturen können in verschiedenen Konfigurationen auftreten. Eine Möglichkeit stellt die in Abbildung 7 dargestellt Peer-to-Peer Verbindung zwischen mehreren Endpunkten dar. Hier subskribiert sich jedes Terminal direkt bei einem anderen Endpunkt, welches sich auf dessen Contact List befindet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Peer to Peer Network

In der Regel wird Presence Information jedoch zentralisiert von einem Presence Server verwaltet. Ein Terminal, welches sich erfolgreich bei einem Server registriert hat und mittels SUBSCRIBE auf Presence Information wartet, muss jedoch keine Kenntnis über die Architektur der Endpunkte besitzen um Notifications empfangen zu können. Um sich bei einem User subskribieren zu können, reicht es vollkommen aus einen SUBSCRIBE Request an dessen bekannte Address-of Record zu senden. Die SIP-Standard Routing Mechanismen leiten den Request entsprechenden dem Standard [4] entweder über den entsprechenden Proxy- oder Redirect Server an den zuständigen Presence Server weiter.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Presence Architektur

Wie in Abbildung 9 dargestellt subskribiert sich die jeweiligen PA an einem Watcher, welcher wiederum Presence Information von einem zentralen Presence Server bezieht, an dem die unterschiedlichen PUA deren Status publizieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10 :Presence Architektur innerhalb der SIP Umgebung

Abbildung 10 stellt die unterschiedlichen Presence Agents im Rahmen der SIP Signalisierung nochmals dar.

6. Das Presence Event Package

6.1. Definitionen

- Presence User Agent (PUA): Der Presence User Agent manipuliert Presence Informationen für eine bestimmte Presentity. Die Änderung der Presence Information kann entweder als Begleiterscheinung beim Anlegen eines neuen Users im Rahmen der Registrierung erfolgen oder explizit durch Publizieren eines Presence Dokumentes. Das Event Package erlaubt ausdrücklich mehrere PUAs pro Presentity. Ein Teilnehmer kann demnach mehrere Endgeräte registrieren, von denen jedes unabhängig einen Teil der Presence Information für eine Presentity erzeugen kann. PUAs senden Informationen in das Presence System, stehen jedoch außerhalb dessen und erhalten daher weder SUBSCRIBE noch NOTIFY Messages.
- Presence Agent (PA): Bei einem Presence Agent handelt es sich um einen Netzwerkknoten der SUBSCRIBE Messages erhält, auf diese Request antwortet und durch Aussenden von NOTIFY Messages Presence Information verändert. Ein PA muss Kenntnis über den Presence Status einer Presentity besitzen. Daher muss dieser Zugriff auf die vom PUA manipulierten Presence Daten besitzen. Eine Möglichkeit wäre, dass der PA mit dem zugehörigen Registrar bzw. Proxy oder mit dem PUA der jeweiligen Presentity assoziiert ist. Ein PA kann immer mit einer SIP URI adressiert werden, welche die Presentity eindeutig identifiziert. Ein PA agiert dem Event Frame Work gemäß auch als Notifier, wobei mehrere PAs für eine bestimmte Presentity zulässig sind.
- Presence Server: Bei einem Presence Server handelt es sich um ein physikalisches Gerät, welches sowohl als PA oder als Proxy Server Subscriber Requests behandeln kann. Als PA besitzt dieser Kenntnis über die Presence Information der jeweiligen Presentity. In Falle eines Proxy, leitet diese die SUBSCRIBE Requests an eine andere Presentity, welche als PA fungiert, weiter. Presence Server werden auch als State Agents bezeichnet. Unter einem State Agent versteht das Presence Event Package jenen PA der nicht an einen PUA gebunden ist. Dieser sammelt in der Regel Presence Informationen von einem PUA und setzt diese in ein Presence Dokument um.
- Edge Presence Server: Ein Edge Presence Server ist ein PA, der an einen PUA gebunden ist. Dieser besitzt die entsprechende Presence Information, da er ja an die Entity, welche die Information verändert gekoppelt ist.

6.2. Ablauf

Eine Entity (SUBSCRIBER) generiert einen SUBSCRIBE Request um an Presence Informationen über einen bestimmten Teilnehmer zu gelangen. Mittels der Request URI (SIP URI, SIPS URI oder Presence URI) wird der gewünschte Teilnehmer angesprochen. Über die gewohnten SIP Routing Regeln wird der Request über Proxys schließlich zu einem Presence Server weitergeleitet, der mittels einer Response Message antwortet und somit die Funktion eines PA für die entsprechende Presentity übernimmt. Er kann den Request jedoch auch an einen Edge Presence Server weiterleiten, der dann als PA auf den Request antwortet. Der Presence Server authentifiziert und autorisiert nun die Subscription. Bei erfolgreicher Autorisierung antwortet dieser mit einem 200 OK Response, andernfalls (eine erfolgreiche Autorisierung ist derzeit noch nicht möglich) mit einem 202 pending Response. In beiden Fällen jedoch sendet der PA jedoch sofort einer NOTIFY Message aus, welche den Status der Presentity und der Subscription beinhaltet.

Der Status gibt jedoch derzeit noch keinen Aufschluss über die Presentity (Privacy Protection), sofern die Subscription nicht erfolgreich autorisiert ist und beinhaltet daher z.B. den Status offline. Sobald sich der Status der Presentity ändert, generiert der PA ein oder mehrere NOTIFYs, welche jetzt den Änderungsstatus der Presentity beinhalten und sendet diesen an die erfolgreich autorisierten Subscriber.

Der Status befindet sich dann im Subscription-State Header Field des NOTIFY. Um die entsprechenden NOTIFY und SUBSCRIBE Request ordnungsgemäß verarbeiten zu können, wird deren Status durch eine fortlaufende Sequence Number sichergestellt. Zusätzlich wird noch durch den Record Route Header gewährleistet, dass alle Nachrichten über die Proxys des initialisierenden SUBSCRIBE Request geroutet werden. Die Subscription muss jedoch nach einer bestimmten Zeit wieder erneuert werden, indem innerhalb des gleichen Dialoges ein SUBSCRIBE Refresh gesendet wird. Dieses SUBSCRIBE unterscheidet sich vom initialisierenden SUBSCRIBE Request dadurch, dass der Wert im CSeq Header Field erhöht wurde und zusätzlich ein Tag im To Header Field eingefügt worden ist. Die Subscription wird durch Setzen des Expires Header Fields auf den Wert Null beendet und ein letztes NOTIFY mit dem letzten Werten des Status wird durch den PA übermittelt. Der PA kann ebenfalls die Subscription abrupt terminieren indem dieser ein NOTIFY aussendet, in dem im Subscription-State Header Field der Grund für die Beendigung angeführt ist.

6.2.1. Lebensdauer einer Presence Subscription

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11 : Lebensdauer einer Subscription

Wie in Abbildung 13 dargestellt fordert ein Watcher eine Subscription für eine Stunde an (1). Der Notifier informiert den Watcher, dass dieser erfolgreich subskribiert ist, jedoch nur für eine Dauer von 5 Minuten (2). Nach 3,5 Minuten erhält der PA ein neues Presence Dokument von der entsprechenden Presentity und leitet diese sofort an den Watcher mittels NOTIFY weiter. In dieser Presence Information teilt der PA dem Watcher mit, dass die Subscription in 90 Sekunden ablaufen wird (3). Nach verstreichen der 5 Minuten hat der Watcher keinen Refresh der Subscription gesendet und der Notifier sendet daher ein terminierendes Timeout im Subscription-State Header Field aus.

Abbildung in dieser Leseprobe nicht enthalten

Ein Watcher kann natürlich die Lebensdauer oder Zeitspanne einer Subscription verlängern bzw. erneuern, indem dieser innerhalb des Dialoges ein erneutes SUBSCRIBE sendet. Im nachfolgenden Beispiel fordert ein Watcher eine Dauer von 60 Minuten an, erhält jedoch nur einen Zeitspanne von 5 Minuten. 1 Minute bevor die Subscription beendet wird fordert der Watcher eine weiter Stunde an, erhält jedoch wiederum nur eine Genehmigung für weiter 5 Minuten und terminiert automatisch die Subscription nach Verstreichen dieser Zeitspanne. Die gesamte Subscription Dauer beträgt daher 9 Minuten, da die abgelaufene Zeit ab dem Refresh der Subscription zu berechnen ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12 : Verlängerung einer Subscription

[...]