The Presence Server. Abbeynet/ IP Communication Solution

Transcription

1 The Presence Server Abbeynet/ IP Communication Solution Abbeynet S.r.l. - ex S.S. 131 Km 8,200 - C.P Sestu (CA) Italy - info@abbeynet.com - tel fax

2 CONTENTS 1. Introduction The Concept of Presence Presence in SIP Call Flow Presence processing in heterogeneous envinronments Presence-related Features Buddy lists Profiles 6 2. The Presence Server System Architecture AAA Server Application Server Presence Server Presence Agent SIP Proxy Authorization Rules Server Resource Lists Server XCAP modules XCAP Client XCAP Server Authentication Successful Authentication Failed Authentication RADIUS Authentication Domain processing SUBSCRIBE Requests Notifies PUBLISH Requests Initial Refresh Modify Remove AAM Interface Authentication Authorization GetState Insert/UpdateState DeleteState Insert/UpdateWatcherList DeleteWatcherList GetWatcherList Implementation SUBSCRIBE Processing PUBLISH Processing 20 - The Presence Server - 2

3 Indice 2.11 Authorization Rules Server Server Interface Server Behaviour Software Architecture Redundancy and Performance Load Redundancy Chosen Architecture Support for other Event Packages Administration Interface Provisioning User mode Administrator mode Statistics Publisher list Subscriber list Messages activity Authentication History Short time history 29 Long time history Service Creation Tool References Appendix A An example of SIMPLE Call Flow Appendix B RADIUS extension parameters Parameters Description and Values user_name digest_user_name digest_realm digest_nonce digest_uri digest_method digest_qop digest_nonce_count digest_cnonce digest_response service_type 37 - The Presence Server - 3

4 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 The Presence Server - 4

5 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: 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

6 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 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 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 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 The Presence Server - 6

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

8 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 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 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 for general information about SOAP. - The Presence Server - 8

9 (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.) 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: - The Presence Server - 9

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

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

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

13 2.3.1 Successful Authentication 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, The Presence Server - 13

14 UA Presenza + Radius Client RADIUS Server SUBSCRIBE/PUBLISH without Authorization header 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 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 9 For a description of FreeRadius see The Presence Server - 14

15 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

16 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 Refresh Status information is left unchanged, while the PUBLISH expire time is updated Modify It s similar to the Initial case, but the body must be stored and status information must be updated 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 Authentication Request: AuthenticationRequest(userID) Responses: OK NO Error code - The Presence Server - 16

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

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

19 OK NO Error code GetWatcherList Request: GetWatcherList(watcher) Response: WatcherList 2.10 IMPLEMENTATION 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

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

21 2.11 AUTHORIZATION RULES SERVER 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

22 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) 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

23 2.13 REDUNDANCY AND PERFORMANCE 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

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