The Presence Server. Abbeynet/ IP Communication Solution

The Presence Server Abbeynet/ IP Communication Solution Abbeynet S.r.l. - ex S.S. 131 Km 8,200 - C.P. 79-09028 Sestu (CA) Italy www.abbeynet.com - info@abbeynet.com - tel. +39 070 2339300 - fax. +39 070 229016

CONTENTS 1. Introduction 4 1.1 The Concept of Presence 4 1.2 Presence in SIP 4 1.2.1 Call Flow 5 1.3 Presence processing in heterogeneous envinronments 6 1.4 Presence-related Features 6 1.4.1 Buddy lists 6 1.4.2 Profiles 6 2. The Presence Server System 7 2.1 Architecture 7 2.1.1 AAA Server 7 2.1.2 Application Server 8 2.1.3 Presence Server 8 2.1.4 Presence Agent 9 2.1.5 SIP Proxy 10 2.1.6 Authorization Rules Server 10 2.1.7 Resource Lists Server 10 2.2 XCAP modules 10 2.2.1 XCAP Client 11 2.2.2 XCAP Server 12 2.3 Authentication 12 2.3.1 Successful Authentication 13 2.3.2 Failed Authentication 13 2.4 RADIUS Authentication 13 2.5 Domain processing 14 2.6 SUBSCRIBE Requests 15 2.7 Notifies 15 2.8 PUBLISH Requests 15 2.8.1 Initial 16 2.8.2 Refresh 16 2.8.3 Modify 16 2.8.4 Remove 16 2.9 AAM Interface 16 2.9.1 Authentication 16 2.9.2 Authorization 17 2.9.3 GetState 17 2.9.4 Insert/UpdateState 18 2.9.5 DeleteState 18 2.9.6 Insert/UpdateWatcherList 18 2.9.7 DeleteWatcherList 18 2.9.8 GetWatcherList 19 2.10 Implementation 19 2.10.1 SUBSCRIBE Processing 19 2.10.2 PUBLISH Processing 20 - The Presence Server - 2

Indice 2.11 Authorization Rules Server 21 2.11.1 Server Interface 21 2.11.2 Server Behaviour 22 2.12 Software Architecture 22 2.13 Redundancy and Performance 23 2.13.1 Load 23 2.13.2 Redundancy 24 2.13.3 Chosen Architecture 25 2.13.4 Support for other Event Packages 26 3. Administration Interface 28 3.1 Provisioning 28 3.1.1 User mode 28 3.1.2 Administrator mode 28 3.2 Statistics 28 3.2.1 Publisher list 28 3.2.2 Subscriber list 29 3.2.3 Messages activity 29 3.2.4 Authentication 29 3.3 History 29 3.3.1 3.3.2 Short time history 29 Long time history 30 4. Service Creation Tool 31 5. References 32 6. Appendix A An example of SIMPLE Call Flow 33 7. Appendix B RADIUS extension parameters 36 7.1 Parameters Description and Values 36 7.1.1 user_name 36 7.1.2 digest_user_name 36 7.1.3 digest_realm 36 7.1.4 digest_nonce 36 7.1.5 digest_uri 36 7.1.6 digest_method 37 7.1.7 digest_qop 37 7.1.8 digest_nonce_count 37 7.1.9 digest_cnonce 37 7.1.10 digest_response 37 7.1.11 service_type 37 - The Presence Server - 3

1. INTRODUCTION 1.1 THE CONCEPT OF PRESENCE Presence identifies a means by which an user can dynamically show himself to other users, publishing and sharing its profile info or simply its willing and availability to communicate. At the beginnings Presence was identified by two different status: online and offline, indicating whether a user was available or unavailable for a communication. With the development of communication means and the growing opportunities of interaction between users, the simple online/offline status has become insufficient. Status information not only has to be more detailed ( I m online, but please call me only for urgent reasons ), enhanced with a lot of user information the so-called Rich Presence but must be the most accurate user information available. For this reason, the status information may be composed using systems able to automatically detect status changes (even without the human intervention1). Due to wireless systems, an user can walk freely in a building, an airport, and even a town, without losing its connectivity: where the user is, and which are the potential communication conditions, becomes more important. On one side the user, with its communication tool, its environment, its mood, etc., but on the other side, all the users that are interested in its status: the watchers. Friends, colleagues, sellers, customers, teachers, experts, consultants, etc, each one able to collect the presence information in different ways (different terminals PC soft clients, IP phones, cell phones, smart phones, web pages, etc. and different information filtering). As different ways to provide and collect presence information exist, there s the need to extend an important issue: the Privacy. The user that publishes its information has the right to choose how this information is notified to watchers, in terms of visibility authorizations, and the publisher can also acquire information about its watchers: this is the watcher info concept. In order to implement a presence system like the one described here, it is necessary to guarantee a mechanism for user authentication and service authorization, together with an accounting policy. 1.2 PRESENCE IN SIP From the IETF RFC 3856 ( A Presence Event Package for the Session Initiation Protocol (SIP) ): Presence is defined as the willingness and ability of a user to communicate with other users on the network. Presence management in SIP is just a particular application of the generic concept of subscription to events (RFC 3265). An user (the subscriber) subscribes to a particular event, related to another user (notifier) which is responsible to provide notifies for that event. In the case of Presence, the events to subscribe to are the changes in contacts (called presence entities, or presentities) status information. Tipically the contacts are the ones stored in the user s buddy list. The presentities that whish to push their presence information in the system become publishers, and can ask to be informed on who is willing to access to published information (watchers), and can also ask to know details about them (watcher info2), in order to apply authorization policies. 1 Activity detection software are available and diffused, and users can also set rules that modify their status on a time basis. 2 RFC 3857 - The Presence Server - 4

Introduction The collector of the presence information, that processes subscribes and publishs, and send notifies, is the Presence Server. The actors in the system are: Presentity/Publisher Watcher/Subscriber Presence Server/Notifier Their interactions are schematically described in the following figure: 1.2.1 Call Flow The following is an example of SIP signalling: The watcher sends a SUBSCRIBE request to the Presence Server, which verifies the authorizations and then accepts the request. As soon as the subscription is accepted, the Presence Server retrieves the most recent presentity status information and notifies it to the watcher. When the presentity, at any time, publishes a status change, the Presence Server stores it (updating or - The Presence Server - 5

Introduction overwriting the information previously stored) and notifies it (applying appropriate filtering policies) to the watcher that has subscribed to that presentity. Appendix A shows an example of SIP messages formatting 3. 1.3 PRESENCE PROCESSING IN HETEROGENEOUS ENVINRONMENTS The architecture seen until this point is focused on delivering presence information with the SIP protocol. The presence information can be stored, collected, correlated and distributed using other means or other protocols. Instead of using PUBLISH or NOTIFY requests, presence information can be stored and modified by accessing directly the Presence Server Data Base or memory, allowing non-sip entities to exchange data with SIP entities. For example, a Presence Server can interface, directly or not, with GSM networks, UMTS networks, the internet, etc. In a similar way, information collected by the SIP network can be notified and delivered with means of transport other than SIP, either standard methods (SMS, MMS, etc.) or proprietary methods. 1.4 PRESENCE-RELATED FEATURES 1.4.1 Buddy lists When users in a presence system wish to receive status information from their contacts, they need to store and manage a large number of contact addresses. An useful feature for a Presence Server would be provide a space in which users can store their contact lists, allowing mobile terminals with limited memory capabilities to manage many contacts. This allows also the synchronization of user s contact list among its different devices. XCAP defines an application called resource-lists that deals with this issue. 1.4.2 Profiles Another interesting feature is the storage of user s profile. This allows a user to synchronize its personal detailed information among different devices or clients, and also makes it possible to create Finder services, like people search, address search, white pages, and so on. 3 For a detailed discussion, see RFC 3261, RFC 3265, RFC 3856, RFC 3903. - The Presence Server - 6

2. THE PRESENCE SERVER SYSTEM 2.1 ARCHITECTURE The Presence Server here describer is part of an Application Server called PRESENZA. It is composed by several components, each one representing a different Service. These modules are interdependent: there will be an interfacing among them and among them and the external world. The interfaces should be as much as possible built on standard protocols. The following figure describes how the Presence Server interacts with users, with generic services (Application Server), and with an external AAA server. 2.1.1 AAA Server This Server manages users information needed for providing service access (at least and for example: UserID and Password). The AAA Server is available through the AAA Interface, and can be used by any module needing to authenticate, authorize or account for a user or a service. In order to complete the Presence Server as service enabler application, we ll provide an embedded AAA server. In this way the Service Provider will see Presenza as a black box able to accept user provisioning, and providing AAA features. - The Presence Server - 7

A Provisioning interface will be implemented: see Administration Interface chapter for further details. The product documentation MUST include a detailed description of the provisioning procedures, administration and customer care interfaces. 2.1.2 Application Server The aim of Presenza is to offer a generic presence-based service, not only correlated to specific presence protocols. For this reason we want to offer a generic customizable interface able to offer substantially the same functionalities provided in standard environments. An example of Application Server is a module that store profile information associated with users. Profiles can be shared, by means of any authorization policy. The sharing of profiles can allow the synchronization of information across different endpoints belonging to the same user, or can permit a Finder service to be provided (for example an user can search for users from a specific nation specified in the user profile that are currently online). In this document we don t focus on the services, but on the tools the Presence Server can offer to build such services. An interfacing protocol that we suggest is SOAP4, being enough generic but at the same time customizable and secure. 2.1.3 Presence Server The Presence Server is internally composed by several modules: Presence Agent SIP Proxy (not shown in the following figure) Authorization Rules Server Resource Lists Server 4 See http://www.w3.org/2000/xp/group/ for general information about SOAP. - The Presence Server - 8

(Authorization Rules Server and Resource Lists Server are showed together because they offer the same interface, resulting in a simpler diagram. They are actual different and independent modules.) 2.1.4 Presence Agent The core module of the Presence Server is the Presence Agent. This module can provide the minimal presence service that is to accept watcher subscription, to accept publish requests and to generate appropriate notifies. This service will be provided in SIMPLE5. The Presence Agent will use an AAA Server to authenticate and authorize the users asking to access the presence service. The interface provided by the AAA Server is RADIUS. Presence services can be added or enhanced by interfacing the Presence Agent with other modules. For example, the Presence Agent will interact with Authorization Rules Server and Resource List Server through XCAP and SIMPLE (ua-profile event package). A further generic interface (SOAP) is provided to implement specific services that are not defined by standard means. 5 For SIMPLE and XCAP see: http://www.ietf.org/html.charters/simple-charter.html - The Presence Server - 9

2.1.5 SIP Proxy A routing element is needed inside the Presence Server. The motivation behind this integration is that the Presence Server must handle SIP signalling in an appropriate way, especially from the point of view fo the routing procedures. SIP signalling handling must be efficient and must require only a basic configuration effort: we choose to not implement these carachteristics inside the Presence Server core, but to embed a SER Proxy (in stateless mode no need for a dedicated DB). All the SIP signalling to and from the Presence Server core will flow through the SIP Proxy. The routing rules will be minimal, but in order to facilitate the configuration phase, a web tool will be provided. The product documentation must include a detailed description of configuration procedures, together with a FAQ session and troubleshooting information. 2.1.6 Authorization Rules Server Any entity with associated presence information (presentities) can configure a set of authorization rules used by the Presence Server to process status information notifications delivered to the subscribers. The authorization rules are defined through XCAP. XCAP provides an advanced methodology to reduce the bandwidth and processing load required to guarantee up-to-date information to all users (even the Presence Agent can be seen for some aspects simply as a user). See also XCAP-diff. 2.1.7 Resource Lists Server Resource Lists are SIP URI lists with an assigned identifier. The Resource List Server stores and provides Resource Lists through its XCAP interface. Users can store their Resource Lists, and the Presence Server can query for them and use them to provide the presence service. Combine a set of resource identifiers under a single identifier reduces the bandwidth and the processing load. Resource Lists may be contacts lists stored in the server to allow synchronization among different endpoints used by the same user. The Presence Agent dialogs with the Resource List Server in XCAP protocol. As in the case of Authorization Rules Server, XCAP-diff can be used to optimize bandwidth and processing load. 2.2 XCAP MODULES XCAP6 is a standardized way to use HTTP to store, retrieve and manipulate configuration and application data. XCAP defines the structure of the data store, and a framework for adding new configuration or application data types to this store. XCAP can be used to store any kind of configuration data. New types of data are added to the framework by defining XCAP Application Usages for them. A usage defines the structure of the data it contains (using XML schema) and the initial authorization policies for documents within that usage. Following is a list of applications defined within XCAP: resource-lists rls-services 6 draft-ietf-simple-xcap-08 - The Presence Server - 10

pres-rules pidf-manipulation policy-capabilities presence-policy-capabilities xcap-caps Since XCAP uses a client-server model, to implement the standard communication between the Presence Agent and another XCAP-based module, we need two different entities: an XCAP Client and an XCAP Server. 2.2.1 XCAP Client This module opens a HTTP/S link to the XCAP Server, to store (PUT), retrieve (GET) or delete (DELETE) XML documents. The XCAP Client is a C++ class that the Presence Agent instantiates and uses. The XCAP Client object hides all the protocol details to the Presence Agent that can use it to store, retrieve and delete XML documents. The main operations performed by the XCAP Client are: HTTP/S Link management Digest Authentication Support for PUT/GET/DELETE (the mechanism depends on the specific application) Up-to-date management - The Presence Server - 11

The set of methods provided by the XCAP Client are available for the entities that instantiate it. A partial list is: PutDocument EraseDocument GetDocument to be completed In order to guarantee that the handled XML documents can be always considered up to date, the XCAP Client implements a SIP SUBSCRIBE/NOTIFY mechanism with the XCAP Server. As soon as a subscribed document is refreshed, added or deleted, the XCAP Server informs the XCAP Client with a NOTIFY message. 2.2.2 XCAP Server The XCAP Server handles the HTTP/S connections required by the XCAP Clients, providing a service of XML documents storage. As described for the XCAP Client, this service allows an entity to store (PUT), retrieve (GET) and delete (DELETE) XML documents. The service provided includes these procedures: HTTP/S Links management Digest Authentication AAA RADIUS interface Support for PUT/GET/DELETE (the mechanism depends on the specific application) Up-to-date management XML Schema validation The XCAP Server implements a SIP SUBSCRIBE/NOTIFY mechanism: when a XCAP Client is interested in a particular XML document, it can subscribe that document, and the XCAP Server sends appropriate notifies anytime a subscribed document changes. Each user requesting for a service must be authenticated and authorized: this task is accomplished by the XCAP Server through a RADIUS connections with an AAA Server. The complete set of RADIUS requests must be specified. 2.3 AUTHENTICATION PRESENZA must verify that any user asking for a service has appropriate authentication credentials. AAM is the module that hides to PRESENZA the external AAA procedures and manages user authentication and authorization. Authentication is the procedure that verifies that the user has been previously provisioned (that is, inserted in the list of known users) and that its identity has been certified. Authorization is the procedure that verifies that the user is authorized to use the service it is asking for. In the following figures the AAM module will be shown apart from the Presence Server, but it is a Presence Server component. - The Presence Server - 12

2.3.1 Successful Authentication 2.3.2 Failed Authentication Both authentication and authorization require that data is available through the AAM module, which interact with the users DB (typically associated with the domain the Presence Server is responsible for). 2.4 RADIUS AUTHENTICATION As described in the previous chapters, PRESENZA must authenticate all the incoming requests (SUBSCRIBE, NOTIFY, PUBBLISH): this is done through the Digest Authentication procedure7. Authentication credentials are delivered to PRESENZA within the requests, and PRESENZA interacts with a AAA Server in order to verify those credentials. The protocol used between PRESENZA and the AAA Server is RADIUS: PRESENZA behaves as a RADIUS client that requires an authentication procedure to a RADIUS server: see the sequence diagram in the following figure. 7 For Digest Authentication mechanism see IETF RFC 3261, 22.2. - The Presence Server - 13

UA Presenza + Radius Client RADIUS Server SUBSCRIBE/PUBLISH without Authorization header 401 - Digest Auth request SUBSCRIBE/PUBLISH with Authorization header Is Authorized? YES/NO 200 OK / 403 Forbidden SIP RADIUS PRESENZA instantiates a RADIUS client. This client derives from radiusclient-ng (v 0.5.1)8. The AAA Server is a FreeRadius Server9. RADIUS Extension The RADIUS protocol is not defined in a RFC, but several IETF drafts describing RADIUS and its extensions exist. PRESENZA implements the latest extension: draft-ietf-radext-digest-auth-0610. Appendix B provides a description of the parameters involved in the authentication procedure. 2.5 DOMAIN PROCESSING Typically a Presence Server is associated to a domain. This means that the Presence Server is responsible for users that validate inside that domain. If the Presence Server receives a request for a user belonging to a domain it is not responsible for, it can choose either to forward the request toward the user s domain, acting as a Proxy, or to reject the request. With the insertion of a SIP Proxy inside the system, the Presence Server doesn t need to behave as a Proxy: it can simply delegate all routing decisions to the SIP Proxy. 8 Further details available at http://developer.berlios.de/projects/radiusclient-ng/ 9 For a description of FreeRadius see http://www.freeradius.org 10 http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-06.txt - The Presence Server - 14

2.6 SUBSCRIBE REQUESTS When the Presence Server receives SUBSCRIBE requests from a watcher, it replies according to its authorization rules and to the watched presentity status information. This is a behavioural model: If the presence status of the UA B is not available, the Presence Server will provide a default status value (the so-called Hard State, that can be provided from a user during the provisioning procedure). 2.7 NOTIFIES NOTIFY messages are generated and delivered by the Presence Server. When a change in a status information occurs (due to a PUBLISH or by other means), the Presence Server retrieves (through a request to the AAM module) the list of watchers that need to be notified. The status information (either global or partial) can be inserted in the NOTIFY body, or can be referenced using content indirection. 2.8 PUBLISH REQUESTS When a user wishes to inform its watchers about a status change, he delivers a PUBLISH message to the Presence Server. The Presence Server, after the authorization procedure, must distinguish among four different cases: # Operation Body? SIP-If-Match? Expires Value 1 Initial yes no > 0 2 Refresh no yes > 0 3 Modify yes yes > 0 4 Remove no Yes 0 - The Presence Server - 15

2.8.1 Initial The body must be extracted from the PUBLISH, and delivered to the AAM module which stores it. The subscription expire time must be contracted (see RFC 3903) and delivered inside the 200 OK response. 2.8.2 Refresh Status information is left unchanged, while the PUBLISH expire time is updated. 2.8.3 Modify It s similar to the Initial case, but the body must be stored and status information must be updated. 2.8.4 Remove User data must be removed from the Presence Server. For each of the cases above, an entity-tag must be created and delivered within the 200 OK response. A refreshing PUBLISH contains the entity-tag created in the previous 200 OK response. The Presence Server must create a new entity-tag which must be inserted in the 200 OK response to the refreshing PUBLISH. For each of the cases above, the Presence Server must create and deliver a NOTIFY containing the updated status information (or containing just a part of the status information, or by content indirection). 2.9 AAM INTERFACE Following is a summarize of the functions needed by the Presence Server to communicate with AAM module. 2.9.1 Authentication Request: AuthenticationRequest(userID) Responses: OK NO Error code - The Presence Server - 16

The authentication procedure (with Digest Authentication) is described in the following diagram (see RFC 3261 22): 2.9.2 Authorization Request: AuthorizationRequest(userID, servicetype, userlist) Responses: OK NO Error code 2.9.3 GetState Request: GetState(user) - The Presence Server - 17

Response: State 2.9.4 Insert/UpdateState Request: UpdateState(user, state) Response: OK NO Error code 2.9.5 DeleteState Request: DeleteState(user) Response: OK NO Error code 2.9.6 Insert/UpdateWatcherList Request: UpdateWatcherList(watcher, watched) Response: OK NO Error code 2.9.7 DeleteWatcherList Request: DeleteWatcherList(watcher) Response: - The Presence Server - 18

OK NO Error code 2.9.8 GetWatcherList Request: GetWatcherList(watcher) Response: WatcherList 2.10 IMPLEMENTATION 2.10.1 SUBSCRIBE Processing As soon as a subscription has been authorized, the author of the subscribe request is stored (in the local memory or in the DB) inside the SUBSCRIBETABLE table, where the following parameters are stored: Call-ID From-tag To-tag Watcher URI Watched URI Expires time The first three parameters identify the SIP dialog that is created after the 200 OK response to the SUBSCRIBE has been received11. The other parameters complete the information set required by the notification procedure. The following diagram shows the logical flow involved in a SUBSCRIBE/NOTIFY exchange, and how the watchers list is managed. 11 RFC 3265, 3.1 describes the standard behaviour for SUBSCRIBE processing. - The Presence Server - 19

2.10.2 PUBLISH Processing The publisher that pushes data into the presence system with PUBLISH requests are stored (in the local memory or in the DB) inside the PUBLISHTABLE table, containing the following parameters: Publisher UserID (in the form user@domain) The publisher s presence document Presence document format type Expires time The following diagram shows the logical flow involved in a PUBLISH/NOTIFY exchange, and how the publishers list is managed: - The Presence Server - 20

2.11 AUTHORIZATION RULES SERVER 2.11.1 Server Interface The presence server needs to use a presence authorization mechanism in order to make decisions about incoming subscriptions, and to get the suitable document based on the user the presence document is referred to, his status, the user who makes the request, and the current date/time. The authorization rules server (more properly referred as Policy Server), is responsible to: retrieve authorization information (through XCAP client); get the appropriate authorization policy to use in subscription management; get the appropriate transformation to apply to the presence document to match the given policy. inform the presence server that some authorization is changed, so a new authorization check is needed. A policy server instance must be instantiated into the presence server. The policy server interface to the presence agent consists of two class methods, the first one to retrieve actions, the other one to retrieve transformations. Moreover, the policy server will raise an event (OnPolicyChangedEvent) every time some policy changes, so that the presence agent may apply the policies again. - The Presence Server - 21

2.11.2 Server Behaviour The policy server is an object instantiated within a presence server that is used by the presence agent and communicates via XCAP to a XCAP server to retrieve the authorization policies. The policy server uses a XCAPDocument to hide the XCAP client interface and behaviour. In accordance to the presence rules IETF draft, the authorization policy server is interested on a set of presence documents, so that the set of rule set (to be merged by the policy server) can be retrieved giving to the XCAPDocument the parameters: XCAP Root (an identifier of the XCAP server, to be loaded from a configuration file); AUID (Application Unique ID): pres-rules ; XCAP User Identifier (the user URI). 2.12 SOFTWARE ARCHITECTURE The Presence Server module is implemented by the PresenceServer class, which needs to both receive and send messages, and for this reason contains a PA member variable. PA implements the library interface for all the SIP messages that can be used in a presence system. PA informs the Presence Server when a SIP message (SUBSCRIBE, PUBLISH, MESSAGE, NOTITY, etc.) is received and allows the Presence Server to send a response or a notify. PA is an interface-class containing two member variables, one for the server part (request process and response delivery) and one for the client part (request delivery and response process): these are PAServer (extending ServerTransactionHandler) and PAClient (extending ClientTransactionHandler), respectively. PAServer implements subscription (RFC 3265 and 3856) and publish (RFC 3903) behaviours, and processes dialogs and automatic error responses. PAServer throws events (OnSubscribe, OnPublish, etc) that can be caught from the application that instantiated the PA object. Once the event has been captured, message processing can proceed. When processing a SUBSCRIBE request, the PA first needs to understand if it is a request that initiates a dialog, refreshes it or ends it. Then the PA acts consequently, adding, updating or removing the information about the watcher sending the SUBSCRIBE. In a similar fashion, PUBLISH requests will cause events to be captured from the application, and the publisher information to be added, updated or removed from the memory (or DB). Depending on the published data, the PA will deliver NOTIFYs towards the subscribers. A way to easily obtain server redundancy is to use a common permanent storage system, like a DB. The DB interface is implemented by the DBManager class, which is instantiated by the AAM object that provides the application interface for authentication, authorization and data storage. Due to its need to manage more concurrent requests, the PresenceServer class is an ActiveObject. - The Presence Server - 22

2.13 REDUNDANCY AND PERFORMANCE 2.13.1 Load Performance is a characteristic that measures the number of messages that can be processed during an interval of time. It depends on the implementation choices, both internal (framework, data structures, etc.) and external (network architecture, clustering, etc.). Let s consider a simple structure (fig. 1): Figure 1 In this scenario, a single Presence Server manages all the requests from the UAs belonging to the same domain. The Presence Server needs to query the Users DB in order to: - The Presence Server - 23

Accomplish user authentication and authorization Store users status information Storing status information in a DB allows data persistance: if, for some reason, a Presence Server would crash, data associated to the current presence scenario will continue to be available to other new or previously existing Presence Server instances. The described architecture has the advantage of being simple, but has several limits: let s consider authentication and authorization phases. Each incoming SIP presence request (SUBSCRIBE and PUBLISH) received by the Presence Server must be authenticated, and one solution is for the Presence Server to read from the DB each time an authentication is needed. This procedure may become inefficient as the number of messages to be authenticated raises. Alternatively, the Presence Server could store locally all the data needed to authenticate messages delivered by a user. This means that only the first time a user sends a message that must be authenticated, the Presence Server will read from the DB12. Subsequent requests from the same user will be authenticated using local stored data. The data structure used for local storage could be a list or a map (with better searching performance). It is clear that the enhancement due to local storage depends on the rate of the incoming requests. Generally, we can make this assumption: - Small amount of data to process: local storage - Large amount of data to process: DB storage 2.13.2 Redundancy A way to achieve load balancing is to redound the Presence Server. A classical architecture contains an LVS (Linux Virtual Server) that routes the messages toward the redundant Presence Servers (2 or more), either randomly or in round robin mode. See fig. 2. The LVS offer a single (virtual) interface to users. Architecture 1 This architecture implies that it is not possible to know in advance which instance of Presence Server will receive a message delivered to the LVS. If a single Presence Server (for example, PS-1) stores presence data information about a user, but it doesn t share those information with the other Presence Servers (for example, PS-2 and PS-3), it is obvious that subsequent messages - associated to that user that the LVS routes to PS-2 or PS-3, will be improperly processed. As a result, a redundancy system with LVS imposes a synchronization mechanism, both for authentication/authorization procedures and for presence data storage. 12 We must consider that authentication keys may vary during operations. - The Presence Server - 24

Figure 2 Architecture 2 To avoid problems due to the lack of data synchronization throughout Presence Server instances, a solution could be to assign different sets of users to each Presence Server. The association user- Presence Server instance could be assigned under particular rules. A module (called for example Handler: it is something acting as a Proxy) could route the incoming messages accordingly to these rules (see fig. 3). Each Presence Server will have the same behaviour seen for the architecture described in fig. 1 (being also unaware of the existence of other Presence Server instances). Anyway, even in this scenario, each Presence Server instance must query the user DB in order to complete the authentication and authorization procedures. The Handler module doesn t help here. Architecture 3 A more complex architecture is described in fig. 4: there is no need for any Handler module, because the routing policies are managed by the Presence Server instances. If a Presence Server receives a message addressed to a user which it is not responsible for, it will forward the message to another Presence Server instance, with some routing rules. This behaviour implies a complicated configuration phase. 2.13.3 Chosen Architecture Starting from the observations above, we chose the architecture described in fig. 2, being simple enough, but at the same time allowing an efficient load balancing. The Presence Server instances will store relevant data in the DB, in such a way that messages belonging to the same SIP dialog can be managed by different Presence Server instances. - The Presence Server - 25

Fig. 3 Fig. 4 2.13.4 Support for other Event Packages We discussed about the Presence Event Package. It is possible to generalize the subscription and notification procedures to Event Packages different from presence, like winfo, ua-profile, etc. Event package support is described in RFC 3265, and has been implemented inside the library (see 3.1 and 3.2, RFC 3265). The processing rules described in RFC 3856 for the presence Event Package are implemented at application level, and we can state that even the support for the other Event Packages can be achieved at application level, leaving the RFC 3265 core inside the library. This means that any SUBSCRIBE delivered to the Presence Server can be firstly processed as defined in RFC 3265, and then, accordingly to the specific Event Package, the application will use the proper data structure to store information: this is described in the following figure. - The Presence Server - 26

Winfo Event Package does apply to different event types (for example, it applies to presence: presence.winfo is another event package). We could create a common winfo template and use it to create specific winfo packages. - The Presence Server - 27

3. ADMINISTRATION INTERFACE One or more administrative figures will monitor and manage the Presence Server activity. The interfaces we are proposing are simple web interfaces allowing for user provisioning, status visualization, server operations statistics, and server management (with settings modifiable runtime). 3.1 PROVISIONING This interface has two modes: User Administrator 3.1.1 User mode This mode allows to: Create/Modify a user account Modify user settings, like Hard State (default status used when status is unknown or the watcher is not permitted to view it), black lists (users that are not authorized to view the real presentity s status), visibility lists. 3.1.2 Administrator mode In addition to the operations allowed in User mode, the Administrator mode provides the tools to: Read provisioning statistics (total amount of provisioned users, maximum allowed number of users, etc) Find information among available users data (Finder) 3.2 STATISTICS In order to provide an estimation about the server load or information about presence document type or available services (IM, presence subscription, status publishing), an interface will be available to the administrator. Following is a set of available statistics: 3.2.1 Publisher list In addition to the total amount of publishers, a table with the following parameters is shown: User name Presence document type (PIDF, RPID, etc) - The Presence Server - 28

Administration interface Status 13 3.2.2 Subscriber list In addition to the total amount of subscribers, a table with the following parameters is shown: Watcher user name Watched user name Event type (presence, winfo, etc) 3.2.3 Messages activity Selecting a user, it s possible to view the number of messages received or sent by that user. 3.2.4 Authentication A report on failed and successful authorizations is shown. 3.3 HISTORY In order to provide information on the server activity, it s useful to store a history log regarding publications, subscriptions, messages, authentications, authorizations, etc. Two different levels will be available: Short time history Long time history 3.3.1 Short time history It is handled with specific tables stored in the DB, and will reference a short amount of time (e.g. one week). Data will be easily available through the web interface to the administrator. These are the suggested tables: Publish_History Publisher user name Operation (first/last publication) Date and time Subscribe_History 13 A first implementation will distinguish simply between Online and Offline status. Next releases will show further status details, such as Activity (Busy, Away), and status notes ( Out to lunch ). - The Presence Server - 29

Administration interface Watcher user name Watched user name Operation (first/last subscription) Date and time 3.3.2 Long time history This history will be stored in a file or closed DB, and will reference longer periods of time (even months). It will not be accessible directly from the web, and is designed to provide advanced service debugging. - The Presence Server - 30

4. SERVICE CREATION TOOL The main goal of the Presence Server described here is to enable a Service Provider to implement the services it is willing to provide, without the intervention of the Server developer. We discussed in previous chapters how a standard interfacing policy can boost the interoperability between modules, reducing the effort required by the network insertion and the time needed, as well. - The Presence Server - 31

5. REFERENCES SIP beyond VoIP The next step in IP Communications Revolution, Sinnreich, Johnston, Sparks. VON Publishing LLC - The Presence Server - 32

6. APPENDIX A AN EXAMPLE OF SIMPLE CALL FLOW 1. SUBSCRIBE: SUBSCRIBE sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP host.example.com;branch=z9hg4bknashds7 To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag=12341234 Call-ID: 12345678@host.example.com CSeq: 1 SUBSCRIBE Max-Forwards: 70 Expires: 3600 Event: presence Contact: sip:user@host.example.com Content-Length: 0 2. 200 OK (response to SUBSCRIBE) SIP/2.0 200 OK Via: SIP/2.0/UDP host.example.com;branch=z9hg4bknashds7 ;received=192.0.2.1 To: <sip:presentity@example.com>;tag=abcd1234 - The Presence Server - 33

Appendix A An example of simple call flow From: <sip:watcher@example.com>;tag=12341234 Call-ID: 12345678@host.example.com CSeq: 1 SUBSCRIBE Contact: sip:pa.example.com Expires: 3600 Content-Length: 0 3. NOTIFY NOTIFY sip:user@host.example.com SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hg4bk8sdf2 To: <sip:watcher@example.com>;tag=12341234 From: <sip:presentity@example.com>;tag=abcd1234 Call-ID: 12345678@host.example.com CSeq: 1 NOTIFY Max-Forwards: 70 Event: presence Subscription-State: active; expires=3599 Contact: sip:pa.example.com Content-Type: application/pidf+xml Content-Length:... 4. 200 OK (response to NOTIFY) SIP/2.0 200 OK Via: SIP/2.0/UDP pa.example.com;branch=z9hg4bk8sdf2 ;received=192.0.2.2 To: <sip:watcher@example.com>;tag=12341234 From: <sip:presentity@example.com>;tag=abcd1234 Call-ID: 12345678@host.example.com CSeq: 1 NOTIFY 5. PUBLISH PUBLISH sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hg4bk652hsge To: <sip:presentity@example.com> From: <sip:presentity@example.com>;tag=1234wxyz Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length:... - The Presence Server - 34

Appendix A An example of simple call flow [Published PIDF document] 6. 200 OK (response to PUBLISH) SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com;branch=z9hg4bk652hsge ;received=192.0.2.3 To: <sip:presentity@example.com>;tag=1a2b3c4d From: <sip:presentity@example.com>;tag=1234wxyz Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH SIP-ETag: dx200xyz Expires: 1800 7. NOTIFY NOTIFY sip:user@host.example.com SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hg4bk4cd42a To: <sip:watcher@example.com>;tag=12341234 From: <sip:presentity@example.com>;tag=abcd1234 Call-ID: 12345678@host.example.com CSeq: 2 NOTIFY Max-Forwards: 70 Event: presence Subscription-State: active; expires=3400 Contact: sip:pa.example.com Content-Type: application/pidf+xml Content-Length:... [New PIDF document] 8. 200 OK (response to NOTIFY) SIP/2.0 200 OK Via: SIP/2.0/UDP pa.example.com;branch=z9hg4bk4cd42a ;received=192.0.2.2 To: <sip:watcher@example.com>;tag=12341234 From: <sip:presentity@example.com>;tag=abcd1234 Call-ID: 12345678@host.example.com CSeq: 2 NOTIFY Content-Length: 0 - The Presence Server - 35

7. APPENDIX B RADIUS EXTENSION PARAMETERS 7.1 PARAMETERS DESCRIPTION AND VALUES 7.1.1 user_name This attribute holds the UA user name. PRESENZA uses the client user name. 7.1.2 digest_user_name This attribute holds the user name used in the HTTP/SIP digest calculation. The RADIUS server MUST use this attribute only for the purposes of calculating the digest. In order to determine the appropriate user credentials, the RADIUS server MUST use the User-Name (1) attribute, and MUST NOT use the Digest-Username attribute. This attribute MUST only be used in Access-Request packets. PRESENZA uses the client user name. 7.1.3 digest_realm This attribute describes a protection space of the RADIUS server. See [RFC2617] 1.2 for details. It MUST only be used in Access-Request and Access-Challenge packets. In Access-Requests, the RADIUS client takes the value of the realm directive realm-value according to [RFC2617]) without quotes from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the RADIUS server puts the expected realm value into this attribute.the value used is abbeynet.com. 7.1.4 digest_nonce This attribute holds a nonce to be used in the HTTP/SIP Digest calculation. If the Access- Request had a Digest-Method and a Digest-URI but no Digest-Nonce attribute and the RADIUS server is configured to choose nonces, it MUST put a Digest-Nonce attribute into its Access- Challenge packet. This attribute MUST only be used in Access-Request and Access-Challenge packets. It s generated by the RADIUS client. 7.1.5 digest_uri This attribute is used to transport the contents of the digest-uri directive or the URI of the HTTPstyle request. It MUST only be used in Access-Request packets. It s the US URI: sip:user_name@host. - The Presence Server - 36

Appendix B Radius extension parameters 7.1.6 digest_method This attribute holds the method value to be used in the HTTP/SIP Digest calculation. This attribute MUST only be used in Access-Request packets. The method is MD5. 7.1.7 digest_qop This attribute holds the Quality of Protection parameter that influences the HTTP/SIP Digest calculation. This attribute MUST only be used in Access-Request and Access-Challenge packets. A RADIUS client SHOULD insert one of the Digest-Qop attributes it has received in a previous Access- Challenge packet. RADIUS servers SHOULD insert at least one Digest-Qop attribute in an Access- Challenge packet. Digest-Qop is optional in order to preserve backward compatibility with a minimal implementation of [RFC2069]. It s generated by the RADIUS client. 7.1.8 digest_nonce_count This attribute includes the nonce count parameter that is used to detect replay attacks. The attribute MUST only be used in Access-Request packets. It s generated by the RADIUS client. 7.1.9 digest_cnonce This attribute holds the client nonce parameter that is used in the HTTP/SIP Digest calculation. It MUST only be used in Access-Request packets. It s generated by the RADIUS client. 7.1.10 digest_response If this attribute is present in an Access-Request message, a RADIUS server implementing this specification MUST treat the Access-Request as a request for Digest Authentication. When a RADIUS client receives a (Proxy-)Authorization header, it puts the request-digest value into a Digest- Response attribute. This attribute (which enables the user to prove possession of the password) MUST only be used in Access-Requests. It s generated by the RADIUS client. 7.1.11 service_type This attribute is used to determine the service type. PRESENZA uses auth_radius (15). - The Presence Server - 37