and report its user's activity to a central server. Both data and voice ... Presence. Voice. Processing. Platform. SIP-enabled. IP PBX. Web Server. SIP Endpoints ...
Enhancing Enterprise Communications Systems with Wireless Devices and Presence Information Knarig Arabshian Columbia University Department of Computer Science New York, NY 10027
Lynne Shapiro Brotman, Michael J. Sammon, Dorée Duncan Seligmann Avaya Labs Research 233 Mt Airy Road Basking Ridge, NJ 07920 Abstract - Features in enterprise communication systems are becoming more and more complex as users demand more functionality and support for the growing variety of devices. Features range from simple telephony features such as hold, call forward and multi-way conferencing to unified messaging and communications. In this paper, we describe adding presence and location information via mobile wireless devices to enterprise communications systems. We wish to move beyond “anyone, anywhere, anytime, anyway” communications to systems that can connect “the right person, at the right place, at the right time, and in the right way.” Presence and location are key ingredients to realizing this vision. We chose to work with SIP, Bluetooth, and J2EE and describe our experiences integrating these with presence services.
INTRODUCTION Communications capabilities in the corporate environment have been evolving over the last several years. Technologies range from primitive analog key systems for small businesses to digital Centrex switches for large businesses. Unified Communications services (integration of telephony services with email, Instant Messaging (IM), and Internet services) have enhanced enterprise communications. However, many of these services can be further enriched with the addition of presence information. By presence, we mean not only online presence but also physical presence, i.e., the x-y location of a person or object. By combining information about the activity in which a person is currently engaged, a person’s expertise, personal communications preferences and specified availability, as well as the situation at hand, a complete snapshot of the current context can be developed. This context information can be utilized by communications applications to determine how and when to provide services. Examples of context-aware functionality include: • Finding the right people, using the right devices, automatically, e.g., “Get me any doctor with expertise X nearest the Emergency Room,” “Send the image to the display closest to that doctor.”
• • •
Emergency response, e.g., “Broadcast warning message to people located within 100 meters of toxic spill.” Location tracking and mapping, e.g., “Guide me to the bin in the warehouse that contains Y parts.” Improved security, e.g., “Automatically log user off system if they are more than 10 meters away.”
Wireless, pocket-size devices such as mobile phones and Personal Digital Assistants (PDAs) have become so widespread in enterprises that it would be hard to find someone who was not carrying at least one such device at any given time. These devices, by virtue of their ubiquity, are a good choice for providing dynamic context information; they can be used to find and track users. These devices typically operate independently from the enterprise’s communications systems and services. By providing an infrastructure that allows the integration of these devices with the enterprise’s communications systems a path can be established for producing and consuming presence information. In this paper we describe an architecture for such an infrastructure. We present our choices of technology for building this architecture. Finally we describe some of the applications we have implemented using this architecture and the implementation issues that arose. SYSTEM ARCHITECTURE In Figure 1 we show an architecture that supports a plethora of wireless devices. We chose Bluetooth as the short-range wireless technology for connecting these devices with enterprise communications systems. A wide-variety of consumer devices and an increasing number of enterprise devices include Bluetooth technology. Bluetooth technology has some features that make it well suited for this application. Bluetooth can form ad hoc piconets and can support both asynchronous data channels and synchronous audio channels. Bluetooth access points whose physical distribution is known can be used to track the location of
Application Server
Bluetooth Devices
…
Applications Location
Bluetooth Wireless Devices Presence Service
Bluetooth Access Point
Web Server
Voice Processing Platform
Enterprise IT (e.g. printers, fax, info sys)
SIP UA
Presence
SIP-enabled IP PBX
SIP Endpoints
Figure 1 Bluetooth endpoints as they move throughout the coverage area. Bluetooth devices, with some additional software, can be used to collect context information. For example, a small monitoring program on a Bluetooth enabled PDA can detect and report its user’s activity to a central server. Both data and voice need to be supported in this infrastructure; our architecture must support a converged communications environment. The Session Initiation Protocol (SIP) [1] is an appropriate choice because it supports signaling, event notification and presence-based communications. SIP addressing maps users to devices dynamically. SIP also inherently supports the notion of presence through SUBSCRIBE/NOTIFY messages, making it an ideal choice for presence-based converged communications. BLUETOOTH AS A PRESENCE/TRANSPORT MEDIUM Bluetooth [2] was originally developed by Ericsson as a cable replacement technology. Only recently has Bluetooth become available in consumer electronics such as hands free cell phone headsets, PDAs and cameras. We believe that acceptance of Bluetooth technology in the consumer marketplace will eventually lead to acceptance in the corporate environment and thus drive new applications and services in the IT and telecomm departments. Bluetooth has a number of attributes that make it attractive to use in a presence-based communications system. First are the power requirements of Bluetooth. Most Bluetooth
devices are Class 3 (1mW) devices. This relieves the device of having to include large batteries onboard. First generation headsets had continuous talktimes of about 3 hours. Current devices have talktimes of 7 hours or more. Bluetooth also has the capability to put devices into hold mode where the battery life can be further extended. Second, with these low power requirements, the batteries can be very small. Thus, Bluetooth devices can be engineered to be extremely portable and wearable. Bluetooth shows promise in efforts to fabricate digital jewelry (e.g., the IBM Research Linux wristwatch [3] with onboard Bluetooth). If these devices can be worn, then associating a person with a device becomes less problematic. Third, because of the low power attributes, the range of transmission is about 10 meters for 1mW devices. While this may seem like a disadvantage at first (in comparison to 802.11’s 100 meter range), Bluetooth’s shorter range provides a finer resolution for obtaining location information. Fourth, Bluetooth has built in security as part of the protocol. This minimizes unwanted intrusions into communications links. Fifth, the Bluetooth protocol includes specific profiles that define the interoperability between devices. One can provision access points to support any set of profiles. Thus, it is relatively easy to restrict access to only certain types of devices or services.
Finally, Bluetooth has synchronous audio capabilities as part of the protocol. A Bluetooth access point can have up to three simultaneous audio links. If one needs to support additional audio streams, then more access points would be necessary. Presence detection with Bluetooth can be accomplished using the Inquiry/Page part of the protocol. Inquiry is equivalent to asking, “Who is out there?” and is used for discovering other devices. Paging is the process by which a connection is setup between two devices. SIP AS A TRANSPORT/TELECOMMUNICATIONS MEDIUM The Session Initiation Protocol, described in RFC 3261, was developed in the IETF as a text-based signaling protocol. Although SIP is mainly used for initiating call sessions between two or more endpoints, it has recently been enhanced to incorporate presence and event notification. This enhancement can unify converged communications applications by allowing one protocol to control the underlying communication [4]. A SIP-enabled presence server can be used to manage the presence of Bluetooth devices and their users. Two methods SUBSCRIBE and NOTIFY, have been defined and can handle presence information [5]. In our implementation, a presence server subscribes to a Bluetooth access point by sending a SIP SUBSCRIBE message to it. When a Bluetooth device is turned on, the access point will immediately send a NOTIFY message to the presence server. The NOTIFY message body can contain an XML body identifying the particular Bluetooth device that has been turned on. Thus, the presence of Bluetooth devices can easily be detected using SIP. Together with a mapping of users to their Bluetooth devices a user’s location can be determined. Communications to and from the Bluetooth endpoints can also be done using SIP. For example, to enable voice communications SIP can be used to initiate phone calls and establish RTP sessions to a Bluetooth headset. A SIP Backto-Back User Agent (B2BUA) [6] that performs third party call control will manage call set up. The B2BUA subscribes to the presence server for notification of the presence of the Bluetooth devices. When a Bluetooth device is detected by one of our access points, a notification is sent to the presence server. The presence server then sends a NOTIFY message to the B2BUA. The presence server maps Bluetooth device presence information to specific users, using a database that maintains the mapping of Bluetooth ID’s of devices and their owners. The user-specific presence information is passed on to the B2BUA using the message body of the NOTIFY message, which also contains all the necessary information to establish an audio connection, including the
IP address of the access point and the port number for the audio stream. The B2BUA, upon receipt of the notification, uses this information to create an SDP message body within a SIP INVITE and initiates an INVITE to a SIP gateway. The “To” header of the INVITE can contain any outside phone number. However, in our proposed architecture, it will contain the number of a voice system where a VoiceXML script will be run. An audio stream is established between the headset, the access point, the SIP gateway and the voice system. The user can make and receive phone calls by voice interactions with the voice attendant script. This architecture can be extended in various ways as SIP supports different forms of multimedia communication. Thus, we can support communications across platforms, text, voice and video. SAMPLE APPLICATIONS In our laboratory we have built prototypes of three applications that utilize this architecture. Prototype 1 demonstrates dynamic routing of audio using SIP, Bluetooth headsets and presence information about the users. In one scenario that we use to demonstrate the system, User1 calls User2 and a call is set up between two SIP endpoints, such as two office phones. When User2 needs to move from his office to the laboratory, he takes his Bluetooth headset with him. When User2 arrives in the laboratory a Bluetooth access point detects his presence. This presence information is communicated to the system and the audio from the call is automatically redirected from User2’s SIP endpoint to the laboratory’s Bluetooth access point to User2’s headset. Prototype 2 demonstrates automatic routing of calls to the phone nearest the Callee using SIP, a Bluetooth PDA, and presence information about the Callee. In the following scenario, the Callee has entered the office of a colleague. Upon entry into the range of the Bluetooth access point in the office, the Callee’s presence is detected via a Bluetoothenabled PDA. That presence information is relayed to the system. Using information about the location of the access point and the devices in that locale, the address of the SIP endpoint (telephone) in the office is then associated with the Callee. Incoming calls for the Callee are then routed automatically to the SIP endpoint in the colleague’s office rather than to the Callee’s office phone, for as long as she remains there. Prototype 3 demonstrates the use of a voice agent for interfacing with enterprise systems using automatic speech recognition (ASR) and Bluetooth headsets. In the following scenario, a Bluetooth access point detects the User’s presence. That presence information is relayed to a SIP B2BUA that had previously registered for notifications
about the User. The SIP B2BUA automatically sets up a link between the User’s Bluetooth headset and a voiceprocessing system. Requests spoken by the User through her Bluetooth headset are interpreted by the ASR engine and fulfilled by the system. This provides direct access to existing voice-based services, including telephony and message management. However, queries can also relate to the presence information. A user can request another user’s location, query what other wireless users are about, or initiate contact based on presence and location information. IMPLEMENTATION We have chosen to work with three emerging technologies: SIP, Bluetooth, and J2EE [7] together with our presence server that is compliant with the PAM [8] and SIP CPIM/PDIF XML interfaces [9,10]. We found that in order to support presence-based communications with mobile wireless devices we had to use these technologies in ways for which they were not originally intended. Consequently, we discovered that our simple experiments were not easily implemented with the existing protocols. For example: though we used SIP for call control and presence notification, we also used it to control the audio streams to non-SIP endpoints – the Bluetooth headsets. Though we used J2EE to integrate with Enterprise information systems, we also used it for computing availability and communication control and integrated it with SIP, resulting in two subscription/notification protocols, and a variety of special-purpose databases. We used Bluetooth devices in ways for which they are not designed: to continuously report a user’s presence and location and also to serve as a “paired” device to an entire building installation, not just one other device or access point (as is the case with the pairing of a cell phone and a Bluetooth headset). A presence and availability server is integral to the functionality we desired, and it too underwent some changes: we needed to extend how presence information would be captured and manipulated and disseminated. Thus, an access point reporting a user’s device’s presence, as described in Prototype 2, leads to the association of an entirely different device to the user based on location. We have used SIP as a convenient way to redirect both calls (audio and signaling) and audio streams to different endpoints when presence information changed. In Prototypes 1 and 3 we use SIP to control communications to endpoints (such as a Bluetooth headset), but the control occurs centrally, not at the device to which the endpoint is connected. We have used Bluetooth devices, both as the means by which to detect users’ presence and/or absence, and also as SIP-controlled endpoints. We have augmented the functionality of an access point to scan for and notify
when devices come into range. Thus our access points, not just SIP endpoints or presence-entities, report presence information about specific devices. The information is then aggregated and coalesced to specify a user’s presence and location using enterprise information systems, including our personnel directory. A device’s association with a user then occurs through third parties. The computed presence information is then used to route calls to any device, not just the presence reporting device, or device whose presence was reported. In other words, arbitrary devices can be used as location badges or active badges [11]. Computation matching devices to people and access points to location provides the necessary information to achieve the presence-based functionality we seek. CONCLUSIONS We wanted to identify the next steps for realizing the new paradigm of building systems that will automatically connect the right people, at the right time, in the right place, in the right ways. We began by exploring the different ways presence and location information can be used and captured. We selected SIP, Bluetooth, and J2EE technologies to experiment with presence-based communication control to see how well they could enable the functionality that we envisioned for future converged communications. This raised some interesting issues, including: • Presence information can be originated by non-presence entities. As such, the subscription notify schemes, based largely in part on buddy lists in AOL Instant Messenger™ for example, are not quite appropriate, particularly when one access point manages communication for several wireless devices. The access points themselves require modification to continuously scan and notify of devices’ presence and absence. • The implied mapping between a device’s presence and the device that is registered as its user’s current communication device is not appropriate for our applications where arbitrary devices are used to report a user’s presence in an environment. • The marriage of SIP and J2EE raises issues of efficiency and throughput that require further exploration. • The Bluetooth protocol does not easily support tracking, hand-off and roaming. For example, it would be useful if devices could remain trackable by other Bluetooth devices while they are in an active connection. FUTURE WORK We are currently building other applications that address an Enterprise’s need for improved communications both for its workforce as well as their end-customers [12, 13]. By using Bluetooth devices as presence/location producers and communication endpoints we can enable new applications that support:
•
Context-aware Services and Hot Zones: dynamically load contact rules based on situation, e.g., location, expertise, authority, devices, availability; • Location-based Services: automatically use the endpoint closest to the user, e.g., route to the closest telephone, printer, fax machine; and • Mobility: support “road warriors” and “corridor cruisers.” With presence-enabled applications comes the promise of increased availability, increased contact completion, reduced costs for mobility, added security, and improved quality of experience for the end-user. ACKNOWLEDGEMENTS We thank our colleagues who have been instrumental collaborators in this work: Yves Jean for our first CommAppServer prototype integrating J2EE, SIP, and presence with our Bluetooth access points; Dave Boyer, Venkat Goud and Anjum Khan for help and modifications of their presence server; Vipul Lalka, Latha Ravishankar and Prem Sumetpong for their support with the SIP2002 demo system shown at N+I; Chris Dingman for his help with SIP and the Avaya Multivantage™ software; Val Matula for assistance in using VoiceXML on the Avaya Interactive Voice Response system. REFERENCES [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, “SIP: Session initiation protocol,” RFC 3261, Internet Engineering Task Force, May 2002. [2] Bluetooth SIG, http://www.bluetooth.com
[3] C. Narayanaswami, et. al., “IBM’s Linux Watch: The Challenge of Miniaturization,” IEEE Computer, vol. 35, pp. 33-41, January 2002. [4] H. Schulzrinne and K. Arabshian, “Providing Emergency Services in Internet Telephony,” SPIE 2002 Conference, Boston. [5] A. B. Roach, “Session Initiation Protocol (SIP)-Specific Event Notification,” RFC 3265, Internet Engineering Task Force, June 2002. [6] J.Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo, "Best Current Practices for Third Party Call Control inthe Session Initiation Protocol", Internet Draft, Internet Engineering Task Force, June 2002. Work in progress. [7] J2EE is a trademark of Sun Microsystems, Inc. http://java.sun.com/j2ee/ [8] Presence and Availability Management (PAM) Forum, http://www.pamforum.org/ [9] B. Campbell, J. Rosenberg, “CPIM Mapping of SIMPLE Presence and Instant Messaging,” Internet Draft, Internet Engineering Task Force, June 2002. Work in progress. [10] H. Sugano, S. Fuimoto, “Common Presence and Instant Messaging (CPIM) Presence Information Data Format,” Internet Draft, Internet Engineering Task Force, May 2002. Work in progress. [11] Frank Stajano, “Security for Ubiquitous Computing.” pp. 28-35, John Wiley and Sons, Ltd., 2002. [12] D. Atkins, D. G. Boyer, M. Handel, J. Herbsleb and T. Finholt, “Introducing Instant Messaging and Presence into the Workplace,” CHI 2002. [13] D. G. Boyer, “Presence Awareness for Future Telecommunication Systems,” in Virtual Reality Technologies for Future Telecommunications Systems, R. Komiya, Ed., in press.
