Network Intelligence for Presence Enhanced Communication [Page 1] SPIRITS Working Group Warren A. Montgomery Rebecca Copeland Expires: May 2002 Network Intelligence for Presence Enhanced Communication draft-montgomery-copeland-presence-spirits-00.txt 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/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In Internet services the concepts of Presence and Availability have been developed to indicate one's ability and willingness to communicate. Presence and Availability are the basis of the widely popular instant messaging services available today and have the potential to be used in many other applications. The exchange of information on presence and availability is being addressed by several IETF standards efforts (IMPP, PRIM, SIMPLE). We believe that the same concepts can be applied to all communications, including voice communications, and will revolutionize the way in which people arrange to communicate and open vast new opportunities for services. We further believe that the intelligent network can be used to achieve this integration. This document describes presence and availability based communication services, and propose how those services can be implemented using the Intelligent Network and SPIRITS. Section 1 of this Internet Draft describes presence based communication services. Section 2 depicts authors ideas on implementation of these services. Section 3 provides conclusions. Sections 4, 5, 6 and 7 respectively provide Authors' Addresses, References, Acronyms and Full Copyright Statement, as required by [1]. 1. PRESENCE BASED COMMUNICATION SERVICES The user of a presence based instant messaging service today receives an indication of which of their colleagues are present, and for each November 2001 Network Intelligence for Presence Enhanced Communication [Page 2] who is present what their availability for communication is. This identities a person, not a communication device, allowing a user to use different communication devices at different times and still be reached through the same user name. Thus when a user sends a message he or she knows the recipient is available to communicate and the message will be heard or read immed iately. This means that the user of a presence based service is far more likely to have effective communication with the person he or she is contacting than a person placing a voice telephone call is today. The effect is to reduce the number of calls which do not reach their destination, reduce the need for messaging (voicemail, pagers and emails) and enhance human interface by speeding up responses. Examples of integrated Presence based communication services include: * Presence directed calling. A user attempting to reach another user directs their call to the userĘs presence. The network automatically routes the call to the appropriate device for the called user based on where the called user has indicated he or she is present and available for the call. * Automatic registration of presence and availability. The network automatically monitors a user's use of communication devices and from that use infers their presence (i.e. which devices that user currently has access to, and at least some aspects of their availability (e.g. a user engaged in a voice call may not be available for other forms of communication)). * Voice Enabled Text Messaging. Instant messaging today is primarily a text service, leaving those who do not currently have access to a text based communication device unable to receive their instant messaging. The network can deliver text messages to voice telephones using text-to-speech (TTS) technology, when finding the user (by his Presence) on a mobile or hands-off device. It is also envisaged that mobile users can hear the Presence status for those they may wish to contact, by means of TTS. * Presence Based Dialing. With presence based communication, the notion of dialing a telephone number in the hope of reaching an individual who uses that telephone is replaced by selecting the individual from a personal or public directory, inquiring about that individualĘs availability, and - if available requesting a call. The network automatically places the call to the called individuals device. * Presence based Conferencing. When multi-party communication is needed, the initiator of a conference can give the network a list of conferees. The network monitors the availability of each of the participants and initiates the conference only when all are simultaneously available. November 2001 Network Intelligence for Presence Enhanced Communication [Page 3] * Wireless Instant Messaging. The combination of SMS over SS7 with IM, together with Presence-based session initiation creates a new wireless IM service. Users can participate in IM sessions from their mobile phones, and interface to PC based IM sessions too whilst on the move. * Presence-based Alerts. These short and pertinent reminders are becoming very important in our time/location critical lifestyle. Urgent alerts can be filtered by Presence and personal preferences and delivered to the currently available device, wherever the user is. * Call Centres and e-CRM. These applications benefit from Presence of agents and knowledge workers who can be called upon wherever they are to support customers. This service increases companies responsiveness to their customers many fold. When Presence becomes commonplace, callers' presence can also be used by these applications to determine which way to respond and where to route the call. 2. IMPLEMENTING PRESENCE BASED COMMUNICATION SERVICES Presence based communication can easily be implemented in an end-to-end IP telephony network, where a communication client can provide both presence information and initiate and receive voice calls. The value of this service is limited however as long as most of the people the user wishes to communicate with are using ordinary telephones which today do not provide presence based communication. Presence based communication can be extended to todayĘs wireless and wireline telephone networks using Intellige nt Networking and the SPIRITS architecture [2] proposed to the Internet Engineering Task Force (IETF). SPIRITS applies the subscribe/notify mechanism of SIP to allow applications to register for notification of events that take place in the PSTN. These building blocks support a new way to establish communications which provides higher value to subscribers by ensuring that each communication reaches the intended person at a time that person can communicate. Presence based communication services require three capabilities of the interface between the PSTN and the service: * Routing calls directed to a user identity based on presence * Monitoring usage to infer presence and availability * Initiating calls without dialing. 2.1. ROUTING CALLS TO A USER IDENTITY Within the telephone network, a user identity must be mapped into a telephone number complying with the appropriate country numbering plan so that the call can be handled by existing network equipment. For a presence based service, calls made to the number representing the userĘs presence must be routed to whatever device (wireless phone, wireline phone, or IP telephony client) that the user has indicated he is available at. Call routing therefore becomes the November 2001 Network Intelligence for Presence Enhanced Communication [Page 4] ability of the network to notify a presence based communication service of attempts to call that number, and the ability of the presence based communication service to direct the routing of such attempts. Notification of attempts to contact a particular telephone number can be accomplished using the intelligent network and the IETF SPIRITS standard to relay IN triggers to the presence based communication service, as illustrated Figure 1. Calls are handled by switches which implement a call model consisting of points in call (PICs) and event Detection Points (DPs) (also known as 'triggers'), as with Intelligent Networking. Events of interest to the application are detected at the switch and sent to an SCP u sing intelligent network protocols, generally over an SS7 signaling network. The SCP acts as a gateway, relaying relevant events to the application server using the SPIRITS protocol [2]. ------- | | | | Internet | Application | | SCP |<--------------->| Server | | | | | ------- | | ^ --------------- | | | SS7 ---------- | | ------ | | /| | | | V / | v | | Call ---------- | O | | | | | | | | Model | Switch | | O | | | | | | | | ----------\ | O | | / \| | | | O---O / | ------ | / \ / ---------- /___\ Figure 1 -- IN to Application Server communication The specific detection points and responses depend on the specific standards for intelligent networking implemented by the switches and SCP. In general, two different DPs can be used to direct a call destined for a number representing a user's identity in the network. The call can be directed using a Terminating Attempt DP in the Terminating Basic Call State Model. In this case the network will first attempt to route the call to a switch which serves the number being used as the caller's personal identit y. This switch, or an intermediate switch, equipped with Intelligent Network Switching Service Function (SSF) software will detect an attempt to terminate a November 2001 Network Intelligence for Presence Enhanced Communication [Page 5] call to the indicated number, notify an SCP of that attempt, which in turn uses the SPIRITS interface to notify an application server. This approach is well suited to most carriers who may wish to offer such a service, since the carrier can use a number which will be routed into that carrierĘs network (through number portability) to capture calls to the user. A second possibility is catch attempts to call the number in the originating call state model in the caller's switch. This is normally done in the Information Analyzed DP, and referred to as a Dialed Number trigger. The switch detects an attempt to originate a call to a particular number, and signals the event to the SCP (and indirectly the presence based application) before a route is selected, allowing the presence based application to substitute a new destination. With this approach the network detec ts that the call requires special treatment sooner, reducing the potential for spending extra resources (extended routing paths, extra switch processing cycles) in routing the call. The problem that arises is that the trigger needs to be enabled in all the switches where such a call may originate, or at least in all the switches through which such a call may pass, which in practice may be much more difficult. In either case, when the application server is notified normal processing of the call is suspended, and the switch and SCP wait for a response. The application server will in general supply a new number to route the call to, a number corresponding to the device at which the called party wishes to receive the call, or a number corresponding to a service node which can perform functions such as recording a message from the caller or playing customized announcements and messages. 2.2. DETECTING PRESENCE AND AVAILABILITY Automatic detection of a user's presence and availability for communication significantly enhances usability of a presence based communication service. Internet based clients generally provide a crude indication of presence by declaring the user present if the client device's keyboard or pointing device has been used recently and the user has not explicitly declared that he or she is not present or not available. The equivalent automated detection in the phone network is to attempt to detect when the use r is reachable via a telephone, and when the user may be available for communication based on use of the telephone device. For wireless phones, detecting presence is relatively straightforward. Wireless phones register with the network when they are turned on and periodically reregister to establish that they are still present. Since wireless phones are generally not shared by more than one person and rarely left on and unattended, if a personĘs wireless phone is on it is highly likely that they are pre sent at that phone. Wireless registrations are directed to a special type of User Agent November 2001 Network Intelligence for Presence Enhanced Communication [Page 6] network server known as the Home Location Register (HLR). These events could be made available directly to the presence application via a SPIRITS interface to the HLR, or more likely could be processed by the HLR to determine whether the phone state has changed and the state change (active or inactive) reflected to the presence application via SPIRITS. In a wireline network, there is no direct equivalent of the registrations of wireless phones that allows the network to detect when a telephone is in use. Furthermore, wireline phones are often not personal, but shared among several people, making it difficult to detect who is using a particular phone. Nevertheless inferring what presence information is available may be useful in helping direct calls to the correct endpoint, and reflecting the availability of the user for communication. There are severa l indications of a userĘs presence: * If calls have been made recently from an endpoint, the user may be at that endpoint. Any one of several detection points in the originating call model at the user's local switch can be used to detect an attempt at originating a call. These include Origination Attempt, Collected Information, Analyzed Information, Origination Authorization, and others. The best event to use can be chosen to minimize interactions with other services. * If calls to an endpoint used by the user are being answered, the user may be present at that endpoint. Here the terminating answered event is the most suitable, and can be relayed to an application maintaining the userĘs presence through the SPIRITS interface and the architecture shown in Figure 1. * If a user has been identified in using a prepaid calling service, Virtual Private Network service, or other network based service which requires the user to identify him/herself from an endpoint, it is likely that the user is present at that endpoint, or at least for a limited period of time. In this case the event of interest is not a call state model event, but rather user identification to a network service. Here use of a network services Application Programming Interface (API) such as Parlay, can b e used. Inferred Presence is best determined through a combination of events such as this and a set of simple rules tailored to the user. The assumption that the user is in the proximity of his normal wireline phone can be made when his profile shows that this number is associated with a PC (or a fixed IP device) which has presence detection capability. Quite simply, when the user is using his PC, he is also near his POTS phone. For a mobile phone, the network may also have information about the location of the phone which may be useful in inferring presence or availability. For example, a user with a mobile phone who also regularly uses wireline phones in a home and an office, the rule November 2001 Network Intelligence for Presence Enhanced Communication [Page 7] might be that if the mobile phone is on, the user is present there, while if the phone is off, the user is likely to be present at the office if the mobile phone was last on at a location near the office, or at home if it was last on near there. In addition, availability to communicate could be inferred dependent on the users location, for example the user could indicate that he or she does not want to be disturbed for anything short of emergencies in certain locations that he or she frequently visits. 2.3. ORIGINATING CALLS BASED ON PRESENCE As noted above, it is highly desirable for the system to be able to initiate a call for the user based on presence. In general the user will access the presence service from an IP endpoint, initiate a call and expect the service to then complete it for him. If the user has an IP telephony based voice client, this can be done using a voice gateway and normal procedures for PSTN/IP telephony interworking. It may be desirable, however, for the call to be made from a POTS telephone, though initiated from a PC or a portable IP device. In this case the application could use the IETF PINT interface to initiate a call. A presence based call can also be made through a use of SPIRITS, but using SPIRITS to allow the network to observe the Off hook detection point on the user's telephone and having the service supply the number to be called. This allows a call to be initiated normally, as if the customer had dialed the number, and thus billing and calling features are naturally provided. The sequence looks like this: * The presence based calling server uses SPIRITS to subscribe to the off-hook detection point for the user's phone. * When the user chooses to initiate a call the presence based calling service instructs the user to pick up the phone, without hearing any ringing. The user picks up the receiver and can hear a dialing tone or an announcement. * The local switching system monitoring the phone generates an off-hook event and waits for further instructions. * The off-hook event is relayed to the presence based calling service * The presence based calling service returns the number to be dialed. * The local switch completes the call as if the user had dialed the number. * Note that the presence service does not know whether the call has November 2001 Network Intelligence for Presence Enhanced Communication [Page 8] been completed on not. For usability, the user client should receive some notification of the status of the request, e.g. when the handset is replaced whilst the connection is being attempted. This method preserves the caller's features and billing arrangements and does not use any extra network equipment to start or complete the call. 3. CONCLUSIONS In conclusion, Presence based communication has the ability to change how users establish communication, and provide communication services which offer significant value to subscribers. Many of these services can be provided using a SPIRITS based interface between a presence based communication application server and the PSTN. A SPIRITS based implementation can make presence based communication rapidly available to a broad base of users independent of the devices (wireless, wireline, or internet) that t hey use. Standards for presence based communication services and for the specific events that need to be communicated should be developed as part of the SPIRITS IETF working group. 4. Authors' Addresses Warren A. Montgomery wamontgomery@ieee.org 435 Gayle Ave DeKalb IL USA Rebecca Copeland Rebecca.Copeland@marconi.com Marconi PLC, New Century Park, Coventry, CV3 1HJ UK 5. References [1] S.Bradner, "The Internet Standards Process", RFC2026 [2] L. Slutsman (Editor), I. Faynberg, H. Lu and M. Weissman, "The SPIRITS Architecture." RFC 3136, June 2001 [3] Lu, H. (Editor), I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Yoakum, and L. Robart, "Pre-SPIRITS Implementations of PSTN- Initiated Services." RFC 2995, November 2000. [4] I.Faynberg, et al, "SPIRITS Protocol Requirements", draft-ietf-spirits-reqs-03.txt, work in progress, February, 2001. 6. Acronyms API Application Programming Interface DP Detection Point e-CRM electronic Customer Relationship Management IN Intelligent Network IP Internet Protocol PIC Point In Call PINT PSTN/Internet Interworking November 2001 Network Intelligence for Presence Enhanced Communication [Page 9] POTS Plain Old Telephony Service PSTN Public Switched Telephone Network SCP Service Control Point SIP Session Initiation Protocol SPIRITS Services in the PSTN/IN Requesting InTernet Services SSF Service Switching Function SSP Service Switching Point TDP Trigger Detection Point TTS Text To Speech 7. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. November 2001