Title of Invention	METHOD OF PROVIDING PRESENCE SERVER IN IP MULTIMEDIA
Abstract	The present invention relates to method comprising receiving a registration message, performing a registration transaction with a serving call state control function updating presence information for a user equipment in response to the registation transaction.

Full Text

54+ PRESENCE SERVER IN IP MULTIMEDIA Field of the Invention The present invention relates to the provision of a system architecture in an packet switched environment, and particularly to the implementation in such an architecture of means for providing information about a user's presence. Background to the Invention In third generation (3G) mobile networks services are provided over IP networks, which results in the integration of voice and data applications. One of the major candidates for the emerging new IP based services is to provide information about the user's presence. Presence is defined as subscription to and notification of changes in the communications state of a user. This communications state consists of the set of: communications means; communications address; and status of that user. In third generation networks, call control and the service creation environment are based on a session initiation protocol (SIP), as described m 3'" Generation Partnership Project, Technical Specification Group Services and System Aspects, I? Multi-Media Sub-System - Stage' 2, 30 TS 23.228 version 1.7.0, February 2001. Internet Engineering Task Force, Internet Draft, draft-rosenberg-impp-presence-ol.txt, Rosenberg et al, published 2nd March 2001, the contents of which are incorporated herein by reference as Annex A, proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators. The notion of presence in Rosenberg et al is broader. Subscriptions and notifications of user presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the common presence and instant messaging (CPIM) framework. However, such proposal does not include any consideration of multimedia environments. The SIP extension defined in Rosenberg et al is based on the concept of a presence agent (PA) , which is a new logical entity that is capable of accepting subscriptions (through a SUBSCRIBE message) , storing a subscription state, and generating notifications (through a NOTIFY message) when there are changes in user presence. The aim of this invention is to provide a technique for the session initiation protocol registration, subscription and notification procedures in an internet protocol multimedia subsystem. Summary of the Invention The aim of the present invention is achieved by providing a presence server in the architecture. The presence server is preferably provided as part of the application and services 'cloud' or environment. By providing the presence server in the architecture, subscribers are able to receive information about other subscriber's presence. The present invention is related to 3G?P (3''* Generation Partnership Project) Release 5/6 standardization. In accordance with the present invention there is provided a packet switched environment, including the functionality of a presence server in an application and services environment. The packet switched environment is preferably an internet protocol multimedia environment, and preferably a s'obsystem of an all-IP telecommunications network. In a first embodiment the interrogating call state control function (I-CSCF) updates the presence information in the presence server by forking an incoming REGISTER message. In a second embodiment the serving call state control function (S-CSCF) acts as a presence agent and the presence server provides the task of storing information about the subscribers. In a third embodiment the presence server in the internet protocol multimedia (IM) sub-system behaves as a presence agent and the serving call state control function (S-CSCF) uses a separate REGISTER transaction to update the presence information in the presence server. The invention thus solves the problem of routing of the REGISTER, SUBSCRIBE and NOTIFY messages in an internet protocol multimedia (IM) subsystem. Brief Description of the Drawings The invention will now be described by way of reference to the accompanying drawings, in which: Figure 1 represents the 3G?P Release 5 architecture embodying the present inventions-Figure 2 represen-s the flow of REGISTER messages in a first embodiment of the present invention; Figure 3 represents the flow of SUBSCRIBE messages in a first embodiment of the present invention; Figure 4 represents the flow of NOTIFY messages in a first embodiment of the present invention; Figure 5 represents the flow of SUBSCRIBE messages in a second embodiment of the present invention; Figure 6 represents the flow of NOTIFY messages in a second embodiment of the present invention; Figure 7 represents the flow of REGISTER messages in a third embodiment of the present invention; Figure 8 represents the flow of SUBSCRIBE messages in a third embodiment of the present invention; and Figure 9 represents the flow of NOTIFY messages in a third embodiment of the present invention. Description of Preferred Embodiments The present invention places a presence server in the internet multimedia subsystem of the 3GPP Release 5 architecture as part of the 'application and services cloud'. The internet protocol multimedia subsystem refers to the set of Core Network entities using the services provided by the packet switched domain of the 3GPP Release 5 architecture to offer multimedia services. The entities of the internet protocol multimedia subsystem are the CSCF, the MGCF, the MRF and some adaptation entities. The representation of the extended architecture is shown in Figure 1. Figure 1 is based on a basic 3GPP architecture in accordance with the architecture defined in 3rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; Architecture for an All-IP Network; 3G TR 23.922 version 1.0.0; October 1999, the contents of which are herein incorporated by reference as Annex B. However, the architecture disclosed therein is modified, as shown in Figure 1, to include a presence server in accordance with the present invention. The present invention is particularly concerned with the flow of REGISTER, SUBSCRIBE and NOTIFY messages in a 3GPP network. The present invention will now be described in further detail with reference to three exemplary embodiments of REGISTER, SUBSCRIBE, and NOTIFY message flows. It should be noted that only the necessary parts of the network - and message flows -needed for operation of the present invention are described in the following examples. One general requirement for all the described embodiments is that the user's profile information must contain the name of the presence server associated with that user. The routing of the REGISTER/SUBSCRIBE/NOTIFY messages of a first embodiment is described hereinbelow with reference to Figures 2 to 4. In this first embodiment, the interrogating call state control function (I-CSCF) updates the presence information in the presence server by forking an incoming REGISTER message. A first network corresponds to the visited network of the presence user agent (PUA), and includes user equipment (UE) 200, and a proxy call state control function (P-CSCF) 202. The first network is also the presence agent's network. A second network corresponds to the home network of the presence user agent (PUA), and includes an interrogating call state control function (I-CSCF) 204, a (KSS) 206, a serving call state control function (S-CSCF) 208, and a presence server (PS) 210. A third network corresponds to the home network of the subscriber, and includes a UE subscriber 212, a first proxy call state control function (P-CSCF#1) 214, a first serving call state control function (S-CSCF#1) 216, an interrogating call state control function (I-CSCF) 218, a (KSS) 220, a second serving call-state control function (S-CSCF#2) 222, and a second proxy call state control function (P-CSCF#2) 224. Referring to Figure 2, there is illustrated an extended registration message flow in accordance with this first embodiment of the present invention. As represented by step 230; the routing of the REGISTER message, initiated by the user equipment 200, takes place between the UE 200; the first network P-CSCF 2 02 and the second network I-CSCF 204. The name of the presence server 210 is part of the subscriber's profile, and this is retrieved by the I-CSCF 204 from the HSS 206 in a step 232. In a step 234 the I-CSCF 204 selects a S-CSCF for the session initiation; which in this example is the S-CSCF 208. As represented by messages 236 and 238, the I-CSCF 204 forks the incoming REGISTER message such that, in accordance with this embodiment, it is forwarded to both the S-CSCF 208 and the PS 210. Thereafter "200 OK" messages are transmitted back to the UE 200 along the reverse route. Referring to Figure 3, there is illustrated a routing of the SUBSCRIBE message flow in accordance with this first embodiment of the present invention. As represented by messages 240, 242, and 244, the SUBSCRIBE message is routed to the I-CSCF 2 04 from the UE subscriber 212 via the P-CSCF#1 214 and S-CSCF#1 216. As represented by message 246, the I-CSCF 204 routes che received SUBSCRIBE message directly to the PS 210. Thereafter "202 Accepted" messages are routed back to the US subscriber along the reverse route. Referring to Figure 4, there is illustrated a routing of the NOTIFY message flow from, the presence server 210 in accordance with this first embodiment of the present invention. The PS 210, as represented by the message 248, forwards che NOTIFY message to the I-CSCF 218. Following a local query to the HSS 220 in step 249 the I-CSCF, as represented by messages 250, 252 and 254, forwards the NOTIFY message to the UE subscriber 226 via the S-CSCF#2 222 and the P-CSCF#2 224. Thus the PS 210 sends the NOTIFY message directly to the other networks I-CSCF 218. Once again, "200 OK" messages are routed back to the PS 210 along the reverse route. In summary, the first embodiment sets the following new requirements to the network elements placed in the architecture: 1. I-CSCF downloads (part of) the subscriber's profile from HSS in order to find the subscriber's presence server; 2. I-CSCF forks the incoming REGISTER of PUA to the S-CSCF and to the presence server; 3 . I-CSCF routes the incoming SUBSCRIBE requests to the presence server directly; and 4. The presence server sends the outgoing NOTIFYs directly to other network's I-CSCF. The routing of the SUBSCRIBE/NOTIFY messages in accordance with a second embodiment of the invention is described hereinbelow with reference to Figures 5 and 6. Since the S-CSCF stores the subscriber profile and the contact information provided in the REGISTER message, a trivial solution is for the S-CSCF to act as a presence agent. One possible problem with this solution is that the S-CSCF would have to store information about all the subscribers and generate NOTIFY messages to all of them. Therefore, in the second described embodiment, the task cf storing information about each subscribers is provided by the newly introduced presence server. For the S-CSCF it is enough to receive only the first SUBSCRIBE message for the presentity, since it will generate the NOTIFY message for the one subscription, and this NOTIFY message will be forked to the subscribers by the proxy server, which has the information about the subscribers. The registration flow in this solution corresponds to the normal registration as defined by 3G TS 23.228 version 1.7.0, February 2001, discussed hereinabove in the introduction. The routing of the SUBSCRIBE/NOTIFY messages in accordance with the second embodiment of the present invention is described hereinbelow with reference to Figures 5 and 6. Elements of the first, second and third networks corresponding to elements shown in Figures 2 to 4 are referenced in Figures 5 and 6 using the same reference numerals. In addition to the elements shown in Figures 2 to 4, for the purposes of describing the second embodiment the third network, corresponding to the home network of the subscriber, includes two user equipment subscribers UE sub3#l 302 and UE subs#2 3 04. Furthermore, the second network, corresponding to the home network of the PUA, includes a second serving call state control function S-CSCF#2 306. Referring to Figure 5, there is illustrated a routing of the SUBSCRIBE message flow in accordance with this embodiment: of the present invention. A SUBSCRIBE message from the first user equipment subscriber 3 02 is forwarded to the P-CSCF#1 214, as illustrated by message 308a. Such message is forwarded, in turn, to the S-CSCFttl 216 and the I-CSCF 204 as illustrated by messages 310a and 312a. Following a local q-aery in step 313a, the SUBSCRIBE message is forwarded to the PS 210, as represented by message 314a. Subsequent thereto, the SUBSCRIBE message is forwarded from the PS 210 to the S-CSCF#2 306, as represented by message 316. Responsive to the SUBSCRIBE message 316 from the presence server 210 corresponding to the first user equipment subscriber 302 of the third network, the S-CSCF#2 returns an acknowledgement message by way ot an accept signal, as represented by arrow 318. Similarly a SUBSCRIBE message from the second user equipment subscriber 3 04 is forwarded to the P~CSCF#1 214, as illustrated by message 308b. Such message is forwarded, in turn, to the S-CSCF#1 216 and the I-CSCF 204 as illustrated by messages 31Gb and 312b. Following a local query in step 313b, the SUBSCRIBE message is forwarded to the PS 210, as represented by message 314b. It is not necessary for the presence server 210 to forward any subsecjuent SUBSCRIBE messages from user equipment of the third network, as the S-CSCF#2 306 has already provided a successful acknowledgement. Acceptance signals for each user subscriber are returned to the respective subscribers along reverse paths, responsive to receipt of the message 318 and an appropriate SUBSCRIBE message 314. Referring to Figure 6, there is illustrated a routing of the NOTIFY message flow from the presence server 210 in accordance with this embodiment of the present invention. As represented by message 3 20, a single NOTIFY message is forwarded from the S-CSCF#1 to the presence server 210. The presence server, as represented by message 322a then forwards a first NOTIFY message to the I-CSCF 218. Following a first local query 324a, the first NOTFIY message is forwarded to the first user equipment subscriber 302 via, in turn, the S-CSCF#2 222 and the P-CSCF#2 224, as represented by messages 326a, 328a, and 330a. The presence server, as represented by message 322b also forwards a second NOTIFY message to the I-CSCF 218. Following a second local query 324b, the second NOTFIY message is forwarded to the first user equipment subscriber 302 via, in turn, the S-CSCF#2 222 and the P-CSCF#2 224, as represented by messages 326b, 328b, and 330b. "200 OK" messages are returned to the presence server 210 via a reverse path, and a single "OK" message forwarded to the S-CSCF#l. The routing of the REGISTER/SUBSCRIBE/NOTIFY messages in accordance with a third embodiment of the present invention is described hereinbelow with reference to Figures 7 to 9. The solution described in this third err±)odiment can be summarised as: the presence server in the internet protocol multimedia subsystem behaves as a presence agent, and the S-CSCF uses a separate REGISTER transaction to update the presence information in the presence server. The routing of the REGISTER/SUBSCRIBE/NOTIFY methods is described hereinafter with reference to Figures 7 to 9, Elements of the first, second and third networks corresponding to elements shown in Figures 2 to 6 are referenced in Figures 7 to 9 using the same reference numerals. Referring to Figure 7, there is illustrated an extended registration message flow in accordance with this third embodiment of the present invention. As represented by step 230, the routing of the REGISTER message takes place between the UE 200, the first: network P-CSCF 202 and the second network I-CSCF 204. Thereafter, in a step 702, the I-CSCF 204 selects a S-CSCF 208 for the session initiation, which in this example is the S-CSCF 208. As represented by message 704, the REGISTER message is then forwarded to the S-CSCF 208. The name of the presence server 210 is part of the subscriber's profile, and this is retrieved by the I-CSCF 204 from the HSS 206 in a step 708. Following successful initiation with the S-CSCF 203, a 200 OK" message is transmitted to the UE 200 along a reverse path. Thereafter, as represented by message 710, the REGISTER message is forwarded to the presence server 210. The message 710 constitutes a separate REGSITER transaction with which the S-CSCF updates the presence information in the PS. If the presence update fails at the presence server, the S-CSCF generates a notification to the UE 200 indicating the presence update failure event. For this notification a SIP NOTIFY message can be used, for example, containing an event header with a new presence failure reason code. This example is illustrated in Figure 7 labelled as 711. The NOTIFY is then acknowledged by the UE 200 to the S-CSCF 208 using a "200 OK" message. Referring to Figure 8, there is illustrated a routing of the SUBSCRIBE message flow in accordance with this third embodiment of the present invention. A SUBSCRIBE message from the user equipment subscriber 212 is forwarded to the P-CSCF#1 214, as illustrated by message 712. Such message is forwarded, in turn, to the S-CSCF#1 216 and the I-CSCF 2 04 as illustrated by messages 714 and 716. Following a local query in step 718, the SUBSCRIBE message is forwarded to the S-CSCF#2 306, as represented by message 720. Sxibsequent thereto, the SUBSCRIBE message is forwarded from the S-CSCF#2 306 to the PS 210, as represented by message 720. Thereafter a "202 Accepted" message is sent along the reverse path. Referring to Figure 9, there is illustrated a routing of the NOTIFY message flow from the presence server 210 in accordance with this third embodiment of the present invention. As represented by message 722, a NOTIFY message is forwarded from the presence server 210 to the S-CSCF#1 306. The S-CSCF#l 3 06, as represented by message 724 then forwards the NOTIFY message to the I-CSCF 218. Following a local query in step 726, the NOTIFY message is forwarded to the user equipment subscriber 226 via, in turn, the S-CSCF#2 222 and the P-CSCF#2 224, as represented by messages 728, 730, and 732. Thereafter a "200 OK" message is sent along a reverse path. The new requirements for the network elements placed in the architecture due to the third embodiment cab be summarised as below: 1. The S-CSCF updates the presence information in the PS with a separate REGISTER transaction. 2. If the presence update fails at the PS, the S-CSCF generates a notification message (e.g. SIP NOTIFY using the Evenyt header with a new presence failure reason code) to the UE indicating the presence failure update event. 3. The SUBSCRIBE generated by the subscriber has to be routed by the network as it would be a normal INVITE, only the S-CSCF of the PUA routes the SUBSCRIBE to the PS associated with the presentity. 4. The NOTIFY generated by the PS has to be routed by the network as it would be a normal INVITE. Although the present invention has been described with reference to three exemplary embodiments, the present invention more generally presents ways of implementing the 5 idea presented m Rosenberg et al with 3GPP proposed architecture. Internet Engineering Task Force SIMPLE WG Internet Draft Rosenberg et al. draft-roseaberg-impp-presence-Gl.txt Various Places March 2, 2001 Expires: September 2001 SIP Extensions for Presence STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress- The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "OTi-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of user presence are supported by defining an event package withjin the general SIP event notification framework. This protocol is also compliant with the Common Presence and Instant Messaging (CPIM) framework. 1 Introduction Presence is (indirectly) defined in RFC2778 [1] as subscription to and notification of changes in the communications state of a user. This communications state consists of the set of communications means, communications address, and status of that user. A presence protocol is a protocol for providing such a service over the Internet or any IP network. This document proposes an extension to the Session Initiation Protocol (SIP) [2] for presence. This extension is a concrete instantiation of the general event notification framework defined for SIP [3], and as such, makes use of the SUBSCRIBE and NOTIFY methods defined there. User presence is particularly well suited for SIP. SIP registrars and location services already hold user presence information; it is uploaded to these devices through REGISTER messages, and used to route calls to those users. Furthermore, SIP networks already route INVITE messages from any user on the network to the proxy that holds the registration state for a user. As this state is user presence, those SIP networks can also allow SUBSCRIBE requests to be routed to the same proxy. This means that SIP networks can be reused to establish global connectivity for presence subscriptions and notifications. This extension is based on the concept of a presence agent, which is a new logical entity that is capable of accepting subscriptions, storing subscription state, and generating notifications when there are changes in user presence. The entity is defined as a logical one, since it is generally co-resident with another entity, and can even move around during the lifetime of a subscription. This extension is also compliant with the Common Presence and Instant Messaging (CPIM) framework that has been defined in [4). This allows SIP for presence to easily interwork with other presence systems compliant to CPIM. 2 Definitions This document uses the terrr.s as defined in [1] . Additionally, the following terms are defined and/or additionally clarified: Presence User Agent (FUA): A Presence User Agent manipulates presence information for a presenticy. In SIP terms, this means that a PUA generates REGISTER requests, conveying some kind of information about the presentity. We explicitly allow multiple PUAs per presentity. This means that a user can have many devices (such as a cell phone and PDA) , each of which is independently generating a component of the overall presence information for a presentity. PUAs push data into the presence system, but are outside of it, in that they do not receive SUBSCRIBE messages, or send NOTIFY. Presence Agent (PA): A presence agent is a SIP user agent which is capable of receiving SUBSCRIBE requests, responding to them, and generating notifications of changes in presence state. A presence agent must have complete knowledge of the presence state of a presentity. Typically, this is accomplished by co-locating the PA with the proxy/registrar, or the presence user agent of the presentity. A PA is always addressable with a SIP URL. Presence Server: A presence server is a logical entity that can act as either a presence agent or as a proxy server for SUBSCRIBE requests. When acting as a PA, it is aware of the presence information of the presentity through some protocol means. This protocol means can be SIP REGISTER requests, but other mechanisms are allowed. When acting as a proxy, the SUBSCRIBE requests are proxied to another entity that may act as a PA. Presence Client: A presence client is a presence agent that is colocated with a PUA. It is aware of the presence information of the presentity because it is co-located with the entity that manipulates this presence information. 3 Overview of Operation . In this section, we present an overview of the operation of this extension. When an entity, the subscriber, wishes to learn about presence information from some user, it creates a SUBSCRIBE: request. This request identifies the desired presentity in the request URI, using either a presence URL or a SIP U'RL. The subscription is carried along SIP proxies as any other INVITE would be. It eventually arrives at a presence server, which can either terminate the subscription (in which case it acts as the presence agent for the presentity), or proxy it on to a presence client. If the presence client handles the subscription, it is effectively acting as the presence agent for the presentity. The decision about whether to proxy or terminate the SUBSCRIBE is a local matter; however, we describe one way to effect such a configuration, using REGISTER. The presence agent (whether in the presence server or presence client) first authenticates the subscription, then authorizes it. The means for authorization are outside the scope of this protocol, and we expect that many mechanisms will be used. Once authorized, the presence agent sends a 202 Accepted response. It also sends an immediate NOTIFY message containing the state of the presentity. As the state of the presentity changes, the PA generates NOTIFYs for all subscribers. The SUBSCRIBE message effectively establishes a session with the presence agent. As a result, the SUBSCRIBE can be record-routed, and rules for tag handling and Contact processing mirror those for INVITE. Similarly, the NOTIFY message is handled in much the same way a re-INVITS within a call leg is handled. 4 Naming A presentity is identified in the most general way through a presence URI [4], which is of the form pres:user@domain. These URIs are protocol independent. Through a variety of means, these URIs can be resolved to determine a specific protocol that can be used to access the presentity. Once such a resolution has taken place, the presentity can be addressed with a sip URL of nearly identical form: 3ip:user®domain. The protocol independent form (the pres: URL) can be thought of as an abstract name, akin to a URN, which is used to identify elements in a presence system. These are resolved to concrete URLs that can be used to directly locate those entities on the network. When subscribing to a presentity, the subscription can be addressed using the protocol independent form or the sip URL form. In the SIP context, "addressed" refers to the request URI. It is RECOMMENDED that if the entity sending a SUBSCRIBE is capable of resolving the protocol independent form to the SIP form, this resolution is done before sending the request. However, if the entity is incapable of doing this translation, the protocol independent form is used in the request URI. Performing the translation as early as possible means that these requests can be routed by SIP proxies that are not aware of the presence namespace. The result of this naming scheme is that a SUBSCRIBE request is addressed to a user the exact same way an INVITE request would be addressed. This means that the SIP network will route these messages along the same path an INVITE would travel. One of these entities along the path may act as a PA for the subscription. Typically, this will either be the presence server {which is the proxy/registrar where that user is registered), or the presence client (which is one of the user agents associated with that presentity). SUBSCRIBE messages also contain logical identifiers that define the originator and recipient of the subscription (the To and From header fields). Since these identifiers are logical ones, it is RECOMMEOTED that these use the protocol independent format whenever possible. This also makes it easier to interwork with other systems which recognize these forms. The Contact, Record-Route and Route fields do not identify logical entities, but rather concrete ones used for SIP messaging. As such, they MUST use the SIP URL forms in both SUBSCRIBE and NOTIFY. 5 Presence Event Package The SIP event framework [3] defines an abstract SIP extension for subscribing to, and receiving notifications of, events. It leaves the definition of many additional aspects of these events to concrete extensions, also known as event packages. This extension qualifies as an event package. This section fills in the information required by [3] . 5.1 Package Name The name of this package is "presence". This name MUST appear within the Event header in SUBSCRIBE request and NOTIFY request. This section also serves as the lANA registration for the event package "presence". TODO: Define lANA template in sub-notify and fill it in here. Example: Event: presence 5.2 SUBSCRIBE bodies The body of a SUBSCRIBE request MAY contain a body. The purpose of the body depends on its type. In general, subscriptions will normally not contain bodies. The request URI, which identifies the presentity, combined with the event package name, are sufficient for user presence. We anticipate that document formats could be defined to act as filters for subscriptions. These filters would indicate certain user presence events that would generate notifies, or restrict the sec of data returned in NOTIFY requests. For example, a presence filter might specify that the notifications should only be generated when the status of the users instant message inbox changes. It might also say that the content of these notifications should only contain the IM related information. 5.3 Expiration User presence changes as a result of events that include-. o Turning on and off of a cell phone o Modifying the registration from a softphone o Changing the status on an instant messaging tool These events are usually triggered by human intervention, and occur with a frequency on the order of minutes or hours. As such, it is subscriptions should have an expiration in the middle of this range, which is roughly one hour. Therefore, the default expiration time for subscriptions within this package is 3600 seconds. As per [3], the subscriber MAY include an alternate expiration time. Whatever the indicated expiration time, the server MAY reduce it but MUST NOT increase it. 5.4 NOTIFY Bodies The body of the notification contains a presence document. This document describes the user presence of the presentity that was subscribed to. All subscribers MUST support the presence data format described in [fill in with IMPP document TBD] , and MUST list its MIME type, [fill in with MIME type] in an Accept header present in the SUBSCRIBE request. Other presence data formats might be defined in the future. In that case, the subscriptions MAY indicate support for other presence formats. However, they MUST always support and list [fill in with MIME type of IMPP presence document] as an allowed format. Of course, the notifications generated by che presence agent MUST be in one of the formats specified in the Accept header in the SUBSCRIBE request. 5.5 Processing Requirements at the PA User presence is highly sensitive information. Because the implications of divulging presence information can be severe, strong requirements are imposed on the PA regarding subscription processing, especially related to authentication and authorization. A presence agent MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined for SIP. It is not considered sufficient for the authentication to be transitive; that is, the authentication SHOULD use an end-to-end mechanism. The SIP basic authentication mechanism MUST NOT be used. It is RECOMMENDED that any subscriptions that are not authenticated do not cause state to be established in the PA. This can be accomplished by generating a 401 in response to the SUBSCRIBE, and then discarding all state for that transaction. Retransmissions of the SUBSCRIBE generate the same response, guaranteeing reliability even over UDP. Furthermore, a PA MUST NOT accept a subscription unless authorization has been provided by the presentity. The means by which authorization are provided are outside the scope of this document. Authorization may have been provided ahead of time through access lists, perhaps specified in a web page. Authorization may have been provided by means of uploading of some kind of standardized access control list document. Back end authorization servers, such as a DIAMETER [5], RADIUS [6], or COPS [71, can also be used. It is also useful to be able to query the user for authorization following the receipt of a subscription request for which no authorization information was present. Appendix A provides a possible solution for such a scenario. The result of the authorization decision by the server will be reject, accept, or pending. Pending occurs when the server cannot obtain authorization at this time, and may be able to do so at a later time, when the presentity becomes available. Unfortunately, if the server informs the subscriber that the subscription is pending, this will divulge information about the presentity - namely, that they have not granted authorization and are not available to give it at this time. Therefore, a PA SHOULD generate the same response for both pending and accepted subscriptions. This response SHOULD be a 202 Accepted response. If the server informs the subscriber that the subscription is rejected, this also divulges information about the presentity -namely, that they have explicitly blocked the subscription previously, or are available at this time and chose to decline the subscription. If the policy of the server is not to divulge this imformation, the PA MAY respond with a 202 Accepted response even though the subscription is rejected. Alternatively, if the policy of the presentity or the PA is that it is acceptable to inform the subscriber of the rejection, a 603 Decline SHOULD be used. Note that since the response to a subscription does not contain any useful information about the presentity, privacy and integrity of SUBSCRIBE responses is not deemed important. 5.i Generation of notifications Upon acceptance of a subscription, the PA SHOULD generate an immediate NOTIFY with the current presence state of the presentity. If a subscription is received, and is marked as pending or was rejected, the PA SHOULD generate an immediate NOTIFY. This NOTIFY should contain a valid state for the presentity, yet be one which provides no useful information about the presentity. An example of this is to provide an IM URL chat is the sar,e form as the presence URL, and mark chat IM address as "not available". The reason for this process of 'lying' is that without it, a subscriber could cell the difference between a pending subscription and an accepced subscription based on the exisCence and content of an immediate NOTIFY. The approach defined here ensures chat the presence delivered in a NOTIFY generated by a pending or rejected subscription is also a valid one that could have been delivered in a NOTIFY generated by an accepced subscription. If the policy of the presence server or the presentity is chac it is acceptable to divulge information about whether the subscription succeeded or not. the immediate NOTIFY need not be sent for pending or rejected subscriptions. Of course, once a subscription is accepced. che PA SHOULD generate a NOTIFY for the subscription when it determines that the presence state of the presentity has changed. Section 6 describes how the PA makes this determination. For reasons of privacy, it will frequently be necessary to encrypt the concents of the notifications. This can be accomplished using che standard SIP encrypt ion mechanisms. The encryption should be performed using the key of the subscriber as identified m the From field of the SUBSCRIBE. Similarly, integrity of the notifications is important to subscribers. As such, the concents of the notifications SHOULD be authenticated using one of the standardized SIP mechanisms. Since the NOTIFY are generated by the presence server, which may not have access to the key of the user represented by the presentity, it will frequently be the case that the NOTIFY are signed by a third party. It is RECOMMENDED that Che signature be by an auchority over domain of the presentity. In ocher words, for a user prcs ;user example.coni, the signator of the NOTIFY SHOULD be the authority for example.com. 5.7 Rate Limitations on NOTIFY For reasons of congestion control, it is important that the rate of notifications not become excessive As a result, it Ls RECOMMENDED chat the PA not generate notifications for a single presentity at a rate faster than once every S seconds interested in presence. Ic provides additional information about the Contact addresses that can be used to construct a richer presence document- The "description" attribute of Che Contact header is explicitly defined here to be used as a free-form field chat allows a user to define the status of the presenticy ac that communicacions address. We also allow REGISTER requests to contain presence documenCs, so chat Che PUAs can publish more complex information. Noce chat we do not provide for locking mechanisms, which would allow a client to lock presence state, fecch ic, and updace iC acomically. We believe chac this is noc neeeded for the majority of use cases, and incroduces substantial complexicy. Most presence operations do not require get-before-seC, since Che SIP regiscer mechanism works in such a way chac data can be updated without a get. The application of registered contacts to presence increases the requirements for authenticity. Therefore, REGISTER requests used by presence user agents SHOULD be authenticated using either SIP auchenticacion mechanisms, or a hop by hop mechanism. To indicate presence for instanc messaging, che UA MAY eicher regiscer concacc addresses chat arc SIP URLs with the 'methods" parameter sec Co indicate the method MESSAGE, or it MAY register an IM URL. TODO- This section needs work. Need to define a concrete example of fnapping a register to a presence document, once IMPP generates the document format. 6.1 Migrating the PA Function It is important to realize that che PA function car\ be colocaced with several elemenca: o It can be co-located with the proxy server handling registration* for the presentity. In chia way. che PA knows the presence of the user through regiscrations. o Ic can be co located with a PUA for that presenticy. In che rate of a single PUA per presentity, the PUA knows che state of the presentity by sheer nature of its cc-location. o It can be CO-located m any proxy along the call setup path That proxy can learn the presence state of the presentity by generating its own SUBSCPIBE m order to determine it In this case, che PA is effectively a B2BUA. Because of the soft-state nature of the subscriptions, it becomes possible for the PA function to migrate during the lifetime of a subscription. The most workable scenario is for the PA function to migrate from the presence server to the PUA. and back. Consider a subscription that is installed in a presence server. Assume for the moment that the presence server can determine that a downstream UA is capable of acting as a PA for the presentity. when a subscription refresh arrives, the PA destroys its subscription, and then acts as a proxy for the subscription. The subscription is then routed to the UA. where it can be accepted. The result is that the subscription becomes installed in the PUA. For this migration to work, the PUA MUST be prepared to accept SUBSCRIBE requests which already contain tags in the To field. Furthermore, the PUA MUST insert a Contact header into the 202. and this header MUST be used by the subscriber to update the contact address for the subscription. TODO; Does this work? What about getting a Record-Route in place at the PUA. This might only be possible for refreshes that don't use Route or tags. The presence server determines that a PUA is capable of supporting a PA function through the REGISTER message. Specifically, if a PUA wishes to indicate support for the PA function, it SHOULD include a contact address m its registration with a caller preferences "methods" parameter listing SUBSCRIBE. 1 Mapping to CPIM This section defines how a SIP for presence messages are converted to CPIM. and how a CPIM messages are converted to SIP for presence. SIP to CPIM conversion occurs when a SIP system sends a SUBSCRIBE request that contains a pres URL or SIP URL that corresponds to a user in a domain that runs a different presence protocol. CPIM to SIP involves the case where a user in a different protocol domain generates a subscription that ts destined for a user in a SIP domain. Note chat the process defined b«Xow requires that the gateway store subscription state. This unfortunate result is due to Che need to remember the Call-ID. CSeq. snd Route headers for subscriptions from the SIP side, so that they can be inserted into the SIP KOTIFY generated whena CPIM notification arrives. 7 I SIP to CPIM SIP for presnce is converted to CPIM through a SIP to CPIM abstract gateway service, depicccd in Figure 1. Figure 1: SIP to CPIM Conversion The first step is chat a SUBSCRIBE request is received at a gateway. The gateway generates a CPIM subscription request, with its parameters filled in as follows: o The watcher identity m the CPIM message is copied from the From field of the SUBSCRIBE. If the From field contains a SIP URL. It IB converted to an equivalent pres URL by dropping all S19 URL parameters, and changing the scheme to pres. This conversion may not work - what if the SIP URL has no user name. Plus, converting from a URL back to a URU In this fashion may not do it correctly. o The target identity in the CPIM message is copied from the Request-URI field of the SUBSCRIBE. This may need to be converted to a pres LTPL as well. o The duration parameter in the CPIM message is copied from the Expires header in the SUBSCRIBE. If the Expires header specifies an absolute time, it is converted to a delta-time by the gateway. If no Expires header is present, one hour is assumed. o The transID parameter m the CPIM message is constructed by appending the Call-ID, the URT in the To field, the UKI in the From field, the CSeq and the tag in the From field, and the request URI, and computing a hash ot the resulting string. This hash is used as the transID. Note that the request URI is included in the hash. This is to differentiace forked requests within the SIP network that may arrive at the same gateway. The CPIM service then responds with either a success or failure. In the case of success, the SIP to CPIM gateway service generates a 202 response to the SUBSCRIBE. It adds a tag to the To field in the response, which is the same as the transID field in the success response. The 202 response also contains a Contact header, which is the value of the target from the SUBSCRIBE request. It is important that Che Contact header be set to the target, since that makes sure that subscription refreshes have the same value in the request URI as the original subscription. The duration value from the CPIM success response is placed into the Expires header ot the 202. The gateway scores the Call-ID and Route header set for this subscription. If Che CPIM service responds with a failure, the SIP to CPIM gateway generates a 603 response. It adds a tag to the To field in the response, which is the same as the transID field in the failure response. When the CPIM system generates a notification request, the SIP to CPIM gateway creates a SIP NOTIFY request. The request is constructed using Che standard RFC2S43 (2) procedures for constructing a request wichin a call leg. This will result in the To field containing the watcr.er field from CPIM. and the From tield containing the target field from the CPIM notification The tag in the From field will contain the transID. The presence information is copied into the body of the notification. The Call-IO and Route headers are constructed from the subscription state stored ir. the gateway tf no notification has yet been generated for this subscription, an initial CSeq value is selected and stored. SUBSCRIBE refreshes are handled identically to initial subscriptions as above. If a subscription is received with an Expires of zero, the SIP to CPIM gateway generates an unsubscribe message into the the CPIM system. The watcher parameter is copied from the From field of the SUBSCRIBE. The target parameter is copied from the Request URI field of the SUBSCRIBE. The transID is copied from the tag in the To field of the SUBSCRIBE request. The response to an unsubscribe is either success or failure. In the case of success, a 202 response is constructed in the same fashion as above for a success response to a CPIM subscriber. All subscription state is removed. In the case of failure, a 603 response is constructed in the same fashion as above, and then subscription state is removed, if present. 7.2 CPIM to SIP CPIM to SIP conversion occurs when a CPIM subscription request arrives on the CPIM side of the gateway. This scenario is shown in Figure 2. The CPIM subscription request is converted into a SIP SUBSCRIBE request. To do that, the first step is to determine if the subscribe IS for an existing subscription. That is done by caking the target in Che CPIM subscription request, and matching it against targets for existing subscriptions. If there are none, it xs a new subscription, otherwise, its a refresh. If its a new subscription, the gateway generates a SIP SUBSCRIBE request in the following manner: o The From field in the request is set to the watcher field in the CPIM subscription request o Tn« To field in the request ts set to the target field in the CPIM subscription request o Tfts Cxpir«s header in the SUBSCilIBE request is set to ths duration field in the CPIM subscription request o The tag in th« rrooi field is set to the transID in ths CPIM Subscription request. Figure 2: CPIM to SIP Conversion This SUBSCRIBE message is then sent. If Che subscription is a refresh, a SUBSCRIBE request is generated m Che same way. However, there will also be a tag in the To field. copied from the subscription state in the gateway, and a Route header, obtained from the subscripcion state m the gateway. When a response to the SUBSCRIBE is received, a response is sent to the CPIM system The duration parameter in this response is copied from the Expires header in the SUBSCRIBE response (a conversion from an absolute time to delta time may be needed) . The tran10 in the response is copied from the tag in the From field of the response. If the response was 202, the status is set to indeterminate. If the response was any other 200 class response, the status is set to sucess For any other final response. Che status is set to failure. If the response was a 20C class response, subscription state is The presence server can determine whether TLS is supported by the receiving client based on the transport parameter in the Contact header of its registration. If that registration contains the token "tls" as transport, it implies that the PUA supports TLS. Furthermore, we allow for the Contact header in the SUBSCRIBE request to contain TLS as a transport. The Contact header is used to route subsequent messages between a pair of entities. It defines the address and transport used to communicate with the user agent. Even though TLS might be used between the subscriber and its local proxy, placing this parameter in the Contact header means that TLS can also be used end to end for generation of notifications after the initial SUBSCRIBE message has been successfully routed. This would provide end to end privacy and authentication services with low proxy overheads. SIP encryption MAY be used end to end for the transmission of both SUBSCRIBE and NOTIFY requests. SIP supports PGP based encryption, which does not require the establishment of a session key for encryption of messages within a given subscription (basically, a new session key is established for each message as part of the PGP encryption). Work has recently begun on the application of S/MIME [13] for SIP. 9,2 Message integrity and authenticity It IS important for the message recipient to ensure that the message contents are actually what was sent by the originator, and that the recipient of the message be able to determine who the originator really is. This applies to both requests and responses of SUBSCRIBE and NOTIFY. This is supported in SIP through end to end authentication and message integrity. SIP provides PGP based authentication and integrity {both challenge-response and public key signatures), and http basic and digest authentication. HTTP Basic is NOT PECOMMENDEO. 93 Outbound authentication When local proxies are used for transmission of outbound messages, proxy authentication is RECOMME-N'OEO. This is useful to verify the identity of the originator, and prevent spoofing and spamming at the originating network. 9 4 Replay prevention To prevent the replay of old subscriptions and notifications, all signed SUBSCFXBE and NOTIFY requests and responses MUST contain a Date header covered by the message signature. Any message with a date older than several minutes in the past, or more than several minutes into the future, SHOULD be discarded. Furthermore, all signed SUBSCRIBE and NOTIFV requests MUST contain a Call-ID and CSeq header covered by the message signature. A user agent or presence server MAY store a list of Call-ID values, and for each, the higest CSeq seen within that Call-ID. Any message that arrives for a Call-ID that exists, whose CSeq is lower than the highest seen so far, is discarded. Finally, challenge-response authentication (http digest or PGP) KAY be used to prevent replay attacks. 9.5 Denial of service attacks Denial of service attacks are a critical problem for an open, inter-domain, presence protocol. Here, we discuss several possible attacks, and Che steps we have taken to prevent them. 9.5.1 Smurf attacks through false contacts Unfortunately, presence is a good candidate for smurfing attacks because of its amplification properties. A single SUBSCRIBE message could generate a nearly unending stream of notifications, so long as a suitably dynamic source of presence data can be found. Thus, a simple way to launch an attack is to send subscriptions to a large number of users, and in the Contact header (which is where notifications are sent), place the address of the target. The only reliable way to prevent these attacks is through authentication and authorization. End users will hopefully not accept subscriptions from random unrecognized users. Also, the presence client software could be programmed to warn the user when the Contact header in a SUBSCRIBE is from a domain which does not match that of the From field (which identifies the subscriber). Also, note that as described in (3), if a NOTIFY is not acknowledged or was not wanted, the subscription that generated it ia removed. This eliminates the amplification properties of providing false Contact addresses. 10 Example message flows The following subsections exhibit example message flows, to further clarify behavior of the protocol 10 I Client to Client Subscription with Presentity State Changes This call flow illuscraces subscriptions and notifications that do not involve a presence server. The watcher subscribes to the presenticy, and the subscription is accepted, resulting in a 202 Accepted response. The presentity subsequently changes state (is on the phone), resulting in a new notification. The flow finishes wich the watcher canceling the subscription. F2 202 Accepted presentity->watcher SIP/2.0 202 Accepted Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User To: Resource ;tag=88a7s Call-ID: 3248 543®watCherhost.example.com Cseq: 1 SUBSCRIBE Event: presence Expires: 600 Concacc: sip:presenticy®pres.example.com F3 NOTIFY Presentity->watcher NOTIFY aip:user®waccherhost.example.com SIP/2.0 via : SIP/2.0/UDP pres.example.com:5060 From: Resource ;tag=89a7s To; User Call-ID: 324 854 3®watcherhosc.example.com CSeq: 1 NOTIFY Event: presence Content-TyP^ • applicat ion/xpidC♦xml Content-Length; 120 F5 HOTIFY Presencity->waccher NOTIFY sip:u8er«watCher host.example.com SIP/2.0 Via: SIP/2.0/irDP pres .example.com: 5060 From; Resource To: User Cal1 - ID: 324 854 3®waCcherhost.example.com CSeqr 2 NOTIFY Event: presence Concent -Type : appl icat ion/xpidf 4-xml Content-Length: 120 F6 200 OK watcher->presentity SIP/2.0 200 OK Via: SIP/2,0/UDP pres.example.com:506 0 From: Resource To: User cpres:user®cxample.com> Cal1 10: 3 24 8S4 33watcherhost.example.com CSeq: 2 NOTIFY F8 202 Accepted presentity->watcher SIP/2.0 202 Accepted Via: SIP/2.0/UDP watcherhost.example.com;5060 From: User To : Resource <:pres :presentity . com>. Call-ID: 324854 3(Swacc her host. example . com Event: presence Cseq: 2 SUBSCRIBE Expires:0 10.2 Presence Server with Client Notifications This call flow shows the involvement of a presence server in the handling of subscriptions. In this scenario, the client has indicated that It will handle subscriptions and thus notifications. The message flow shows a change of presence state by the client and a cancellation of the subscription by the watcher. F9 REGISTER PUA->server REGISTER sip;example com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;5060 To: From: Call-ID: 2 818®pua.example.com CSeq: 2 REGISTER Contact: .-methods-^ "MESSAGE" ;description="busy" Contact: ;methods = "SUBSCRIBE" Expires; 600 Fio 200 OK eerver->PUA SrP/2.0 200 OK Via; SIP/2. 0/UT3P pua .example . com: 5060 To: From: Call -ID: 28183ipua . example . com CSeq: 2 REGISTER Contact: .-methods = "MESSAGE" ;description-"busy" Contact: ;methods»-SUBSCRIBE-Expires: 600 F12 200 OK watcher->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: User From: Resource ;Cag«ffd2 Call-ID: 32485®waccherho6t.examp1e.com CSeq : 2 NOTIFY 10 3 Presence Server Notifications This message flow illustrates how the presence server can be the responsible for sending notifications for a presentity. The presence server will do this if the presentity has not sent a registration indicating an interest in handling subscriptions This flow assumes that the watcher has previously been authorized to subscribe to this resource at the server. Message Details Fl SUBSCRIBE watcher->server SUBSCRIBE sip:resource*tfexannple.com SIP/2.0 Via; SIP/2.0/UDP watcherhosc.example.com:5060 To: From: Call-ID: 2010fflwatcherhost,example.com CSeq: 1 SUBSCRIBE Event: presence Accept: application/xpidf-*>xml Contact: Expires: 600 F2 202 OK scrver->watcher SIP/2.0 202 Accepted y/ia: SIP/2.0/UDP watcherhost .example. com:5060 To: cpres:resourceSexample.com>;tag-ffd2 From: Call-ID: 20X0«watcherhost>example.com CSeq: 1 SUBSCRIBE Event: presence Expires: 600 Contact: sip:example.com r> NOTIFY server-* watcher MOTIFY sipTuser^watcherhost.example con SIP/3.0 Via: SIP/2.0/UDP server example com:S060 Rosenberg et al. tP^ge 29] 11 Open Issues The following is the list of known open issues: o This draft recommends chat the To and From field are populated with presence URLs rather than sip URLs. Is that reasonable? will this lead to incompatibilities in proxies? Is there any issues with CPIM if the SIP ISRL format is used? This depends on what components of a message are signed in CPIM. o Rate limitations on NOTIFY: do we want that? How do we pick a value? 5 seconds is arbitrary. o Merging of presence data from multiple PA has been removed. Is that OK? o Placing IM URLs in the Contact header of a REGISTER: is that OK? What does it mean? o The process of migrating subscriptions from a presence server CO PUA ia not likely to work m the case where subscription refreshes use tags and Route headers. So, we have a choice. Either migration is disallowed, and we keep with leg oriented subscriptions» or migration is allowed, and chore is no tags or Route's associated with subscriptions. o Converting SIP URLs back to pres URLs. o The SIP to CPIM and CPIM to SIP gateways are not stateless, because of the need to maintain Route. Call-ID, CSeq, and other parameters. Perhaps wc can ask CPIM to define a token value which is sent in a CPIM request and returned in a CPIM response. Would that help? o The Event header must now be used in the SUBSCRIBE and NOTIFY requests. o The StJBSCRIBE message can only have a single Contact header. -00 allowed for more than one. o The From and To headers can contain presence UKTs . o The Request-URI can contain a presence URI. o Subscriptions are responded to with a 202 if they are pending or accepted. o Presence documents are not returned in the body of the SUBSCRIBE response. Rather, they are sent in a separate NOTIFY. This more cleanly separates subscription and notification, and is mandated by alignment with CPIM. o Authentication is now mandatory at the PA. Authorization is now mandatory at the PA. o Fake NOTIFY is sent for pending or rejected subscriptions. o A rate limit on notifications was introduced. o Merging of presence data has been removed. o The subscriber re3ects notifications received with tags that don't match those in the 202 response to the SUBSCRIBE. This means that only one PA will hold subscription state for a particular subscriber for a particular presentity, o IM URLs allowed in Contacts in register o CPIM mappings defined. o Persistent connections recommended for firewall traversal. Obtaining Authorization when a subscription arrives at a PA. the subscription needs to be authorized by the presentity. In some cases, the presentity may have provided authorization ahead of time. However, m many cases, the subscriber is not pre-authorized In that case, the PA needs to query the presentity for authorization In order to do this, we define an implicit subscription at the PA. This subscription is for a virtual presentity. which is the "set of subscriptions for presentity X", and the subscriber to that virtual presentity is X itself, whenever a subscription is received Cor X, the virtual presentity changes state to reflect the new subscription for X. This state changes for subscriptions that are approved and for ones chat are pending. As a result of this, when a subscription arrives for which authorization is needed, the state of the virtual presentity changes to indicate a pending subscription. The entire state of Che virtual presentity is then sent to the subscriber (Che presenticy itself). This way, the user behind that presentity can see that there are pending subscriptions. It can then use some non-SIP means to install policy in the server regarding this new user. This policy is then used to either accepc or reject Che subscription. A call flow for Chis is shown in Figure 3. In Che case where che presenticy is not online, the problem is also straightforward. When the user logs into their presence client, it can fetch the state of the virtual prea'encicy for X. check for pending subscriptions, and for each of them, upload a new policy which indicates Che appropriate action to take. A data format Co represcnc the state of these virtual presencicies can be found in {14l. A Acknowledgemencs We would like to thank the following people for their support and comments on this draft Rick Workman Nortel Adam Roach Ericsson Sean Olson Ericsson Billy Biggs University of Waterloo Stuart Barkley UUNec Mauricio Arango SUN Richard Shockey Shockey Consulting LLC Jorgen Bjorkncr Hotsip Henry Sinnreich MCI Worldco« Ronald Akera Motorola B Authors Addresses Jonathan Rosenberg Foreword This Technical Report has been produced by the 3GPP. The conicnu of the present documcni arc subject to coniinuing work %vithin the TSG and may change following formal TSG approval. Should the TSG n>odify the conients of this TS. it uiU be re-rclcased by the TSG with an identifying change of release date and an increase m version number as follow^: 3. The standard shall enable the all IP core network to suppon release 99 CS terminals. This shall be sundardised in such a way as to allow operators to decide whether or not ihey wish to support Release 99 CS only terminais. 4.5 Radio aspects The Subscribed QoS level should be maintained across the handover boundary However QoS negotiation (if ncceassarv) should be possible before, during and after the handover (The application may reject the offered QoS) option 2:. One purpose of option 2 is also to allow suppon of release 99 CS domain terminals. In addition option 2 also supports the IP based services of option 1. 5.1.1 Reference Architecture - Option 1 5.1.3 What is the Border of the Network 5.3.11 SGSN to Applications and Services 7.1.2 All IP UTRAN to All IP ERAN Handover Parameters: Handover type. Noic; Procedures related to synchroruzation crc. to GSM BSS are not shown. 8.2 Airlink Optimisation for Real-Time IP This section covers only PS services. 10 Service Platform Impacts 10.1 3GPP Release 2000 Service Architecture 10.2.2.1 Advantages ♦ An open interface based on OSA concepts. APIs that may interface with the CSCF and the CSE arc expected to become available allowing specific protocols to be hidden from the scrvice/appiication designers History CLAIMS: l.A packet switched environment, including a functionality of a presence server in an application and services environment, 2. The Packet switched environment of claim 1 wherein the presence server receives a REGISTER message from an interrogating call state control function in the same network. 3. The Packet switched environment of claim 2 wherein the serving call state control function of the presence server network further receives the REGISTER message. 4. The Packet switched environment of claim 2 or claim 3 wherein the presence server receives SUBSCRIBE message from the interrogating call state control function in the same network. 5. The Packet switched environment of claim 4 wherein the interrogating call state control function receives the SUBSCRIBE message from a serving call state control function in a subscribers home network. 6. The Packet switched environment of claim 5 wherein the serving call state control function receives the SUBSCRIBE message from a proxy call state control function in a subscribers home network. 7. The Packet switched environment of claim 6 wherein the proxy call state control function receives the SUBSCRIBE message from the subscriber. 8. The Packet switched environment of any one of claims 2 to 7 wherein the presence server provides a NOTIFY message to the interrogating call state control function of the subscriber's network. 9. The Packet switched environment of claim 8 wherein the interrogating call state control function provides the NOTIFY message to a proxy call state control function of the subscriber network. 10. The Packet switched environment of claim 9 wherein the proxy call state control function provides the NOTIFY message to the subscriber. 11. The Packet switched environment of claim 1 wherein the presence server receives a plurality of SUBSCRIBE signals from a respective plurality of subscribers in a subscriber network. 12. The Packet switched environment of claim 11 wherein each subscriber provides a SUBSCRIBE message to a proxy call state control function of the subscriber network. 13. The Packet switched environment of claim 12 wherein the proxy call state control function of the subscriber network forwards the respective SUBSCRIBE messages to a serving call state control function of the subscriber network. 14. The Packet switched environment of claim 13 wherein the serving call state control function of the home network provides the respective SUBSCRIBE messages to an interrogating call state control function of the presence server network. 15. The Packet switched environment of claim 14 wherein the interrogating call state control function provides the respective SUBSCRIBE messages to the presence server. 16. The Packet switched environment of any one of claims 11 to 15 wht. rein the presence server provides a single SUBSCRIBE message to a serving call state control function of the presence server network. 17. The Packet switched environment of claim 16 wherein the presence server receives s single NOTIFY message frocn the serving call state control function. 18. The Packet switched environment of claim 17 wherein the presence server generates a NOTIFY message for each respective user subscriber. 19. The Packet switched environment of claim 18 wherein the plurality of NOTIFY messages are received by the interrogating call state control function of the subscriber network. 20. The Packet switched environment of claim 19 wherein the interrogating call state control function forwards the NOTIFY messages to a serving call state control function of the subscriber network. 21. The Packet switched environment of claim 20 wherein the serving call state control function forwards the NOTIFY messages to a proxy call state control function of the subscriber network. 22. The Packet switched environment of claim 21 wherein the proxy call state control function forwards the NOTIFY messages to the respective subscribers. 23. The Packet switched environment of claim 2 wherein the presence server receives a REGISTER message from a serving call state control function in the presence server network network. 24. The Packet switched environment of claim 23 wherein the serving call state control function receives the REGISTER message from an interrogating call state control function of the presence server network: 25. The Packet switched environment of claim 24 wherein a subscriber provides a SUBSCRIBE message to a proxy call state control function of the subscriber network. 26. The Packet switched environment of claim 25 wherein the proxy call state control function of the subscriber network forwards the SUBSCRIBE message to a serving call state control function of the subscriber network. 27. The Packet switched environment of claim 13 wherein the serving call state control function of the subscriber network provides the SUBSCRIBE message to an interrogating call state control function of the presence server network. 28. The Packet switched environment of claim 14 wherein the interrogating call state control function provides the respective SUBSCRIBE messages to a serving call state control function. 29. The Packet switched environment of claim 28 wherein the serving call state control function provides the SUBSCRIBE message to presence server. 30. The Packet switched environment of claim 29 wherein the presence server provides NOTIFY message to the serving call state control function. 31. The Packet switched environment of claim 30 wherein the NOTIFY message is received by the interrogating call state control function of the subscriber network. 32. The Packet switched environment of claim 31 wherein the interrogating call state control function forwards the NOTIFY message to a serving call state control function of the subscriber network. 33. The Packet switched environment of claim 32 wherein the serving call state control function forwards the NOTIFY message to a proxy call state control function of the subscriber network. 34. The Packet switched environment of claim 33 wherein the proxy call state control function forwards the NOTIFY messages to the subscriber. 35. The packet switched environment of any preceding claim, wherein the environment is an internet protocol multimedia environment. 36. The packet switched network of claim 3 5 wherein the internet protocol multimedia environment is a subsystem of an all-IP telecommunications network. 37. A packet switched environment substantially as herein described with reference to the accompanying drawings.

Documents:

1548-chenp-2003 abstract granted.pdf

1548-chenp-2003 claims granted.pdf

1548-chenp-2003 description (complete) granted.pdf

1548-chenp-2003 drawings granted.pdf

1548-chenp-2003-claims.pdf

1548-chenp-2003-correspondnece-others.pdf

1548-chenp-2003-correspondnece-po.pdf

1548-chenp-2003-description(complete).pdf

1548-chenp-2003-form 1.pdf

1548-chenp-2003-form 18.pdf

1548-chenp-2003-form 3.pdf

1548-chenp-2003-form 5.pdf

1548-chenp-2003-pct.pdf