INTERNET-DRAFT Vijay K. Gurbani February 2003 Sudha Gouthama Expires: August 2003 Byron J. Williams Lucent Technologies, Inc. Document: draft-gurbani-spirits-implementation-00.txt Category: Experimental Early implementation of the Services in PSTN requesting Internet services (SPIRITS) protocol 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 This document describes our early implementation of the SPIRITS protocol. The purpose of the SPIRITS protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. 1. Introduction The SPIRITS protocol defines the mechanisms and the semantics to subscribe to and convey certain PSTN events to interested Internet hosts for service execution [1]. This Internet-Draft describes our initial implementation of a SPIRITS framework based on the architecture and requirements outlined in [2] and [3], respectively. We have implemented two services based on such an architecture: a SPIRITS-based presence service which provides a coarse-grained presence status for a user represented by a device (phone), and a SPIRITS-based Instant Messaging (IM) service whereby the PSTN sends a SIP IM to a SPIRITS User Agent (UA). These services, the attendant architecture and the relevant call flows are described next. It is expected that the reader is conversant in the SPIRITS and SIP terminology. For those who are not, [5,6] provide a good reference for SIP and its event-based mechanism, and [1,2,3] provide a good draft-gurbani-spirits-implementation-00.txt [Page 1] Early implementation of the SPIRITS protocol February 2003 reference for SPIRITS. It is important to point out that the SPIRITS protocol [1] is not a standard yet, it is still an Internet-Draft. Thus, what is described in this draft is an early implementation designed to validate the suitability of the protocol as well as provide some implementation experience that will be leveraged in further refining the protocol. 2. Services implemented We implemented two SPIRITS services; the first one is a presence- based service consisting of a user agent (UA) that subscribes to those detection points (DP) in the PSTN which constituted a coarse form of presence -- on-hook, off-hook, and picking the phone up to make (or receive) a call. When such events occurred, two SIP NOTIFY requests were send by the PSTN to the SIP UA. The first NOTIFY request contained the DP that triggered the request, and following it was a NOTIFY that indicated the change in the presence state for a user represented by the phone number. Accordingly, the payload type of the first NOTIFY was "application/spirits-event" and that of the second NOTIFY was "application/cpim-pidf+xml" [4] with local extensions to the element to impart the a richer presence- based component of the service. The SPIRITS UA is thus able to act as an endpoint which can display change in presence status for any CPIM-compliant presence system, including acting as a clients for a SPIRITS-compliant system. The second service demonstrates the capability of the PSTN to send a SIP IM to a SPIRITS UA using the SIP MESSAGE extensions [8]. Under this service scenario, a user in her office may be interested in knowing who called her home while she was at work. Thus, she would like to get real-time notifications of calls terminating to her home line. Accordingly, she subscribes to the DP that gets triggered on an incoming call. When the DP triggers, the PSTN sends out a SIP NOTIFY intimating her of that event, and following the NOTIFY is a SIP MESSAGE request, the body of which contains the date and time the PSTN received the call, and if available, the callers phone number. Our initial thrust in service implementation has been the wireline aspects of the PSTN since these are well formalized by the SPIRITS protocol I-D. SPIRITS supports the wireless services as well, and the next sample set of services will be drawn from that domain. 3. Software needed In order to realize SPIRITS services, we had to write specialized SPIRITS UAs. These UAs, in addition to being conversant with the standard SIP extensions for presence [7] and instant messaging [8], also had to be knowledgeable about SPIRITS. To that extent, they needed the capability to subscribe to the SPIRITS events and receive notifications for them and execute the appropriate service-specific behavior when a notification for these events arrived. draft-gurbani-spirits-implementation-00.txt [Page 2] Early implementation of the SPIRITS protocol February 2003 We wrote two specialized SPIRITS UAs. The first UA, corresponding to the first service, is a presence-based UA that subscribed to the presence- related DPs in the PSTN. It also accepts NOTIFYs containing the SPIRITS payload and NOTIFY requests containing a CPIM document as a payload [4]. We implemented a local namespace to further quantify the element of the CPIM document. In order to realize a SPIRITS framework, a Service Control Function (SCF) associated with a Service Switching Point (SSP) is required (see Figure 1: SPIRITS Architecture in [2]). We had a specialized load on a SSP which sent selected events to another piece of software we authored. This software was the embodiment of a SCF with a co- located SPIRITS client (as depicted in Figure 1 of [2]). The SPIRITS client accepted SIP SUBSCRIBE requests from Internet hosts and maintained a subscription database in the SCF. When the SCF got notified of an event by the SSP, the subscription database was checked to see if an Internet host had subscribed to such an event. If so, a SIP NOTIFY was sent, followed by any other service-specific SIP extension. For example, if the SPIRITS client "knew" that a SPIRITS UA supported the MESSAGE extension (through the "Allows" SIP header), it would also send out a SIP MESSAGE request to the client (thus realizing the IM service). In the absence of any such indication, a plain NOTIFY would be sent out. Note that the machinations described above for SSP and SCF communications are incidental, and in fact, the SPIRITS protocol does not deal directly with this interface. What is of utmost importance is the behavior of the SPIRITS UA; more specifically, the behavior of the SPIRITS client (in the PSTN domain) and that of the SPIRITS server (in the Internet domain). The SPIRITS server (or subscriber) simply sent out a SIP SUBSCRIBE with the Event token and payload as specified in [1] and the SPIRITS client (or notifier) sent out a SIP NOTIFY with the payload and behavior as specified in [1]. The SPIRITS WG is chartered to specify the syntax and semantics of communication between the SPIRITS client and the SPIRITS server. What the SPIRITS server does on receiving a SIP NOTIFY is beyond the need for standardization; it depends on the creativity that leads to novel services. Likewise, what the SPIRITS client does on receiving a SIP SUBSCRIBE depends on the service provider and the representation of their network. 4. Detailed call flows We now present the detailed call flows for the two services. The call flows are presented as vertical time-line diagrams, with the messages being exchanged between the entities represented as horizontal lines. Each such line has a corresponding number (Fn) and the contents of that message are described in detail after the call flow. For brevity, the messages are directly exchanged between the SPIRITS server (subscriber) and the SPIRITS client (notifier). Intermediaries like the SPIRITS gateway or proxies are not represented in the call flows. Also, we have chosen not to show the draft-gurbani-spirits-implementation-00.txt [Page 3] Early implementation of the SPIRITS protocol February 2003 contents of the 200 OK responses. 4.1 Presence SPIRITS server SPIRITS client (subscriber) (nofitier) 192.168.1.1 192.168.1.2 |F1 (SUBS) | +---------------------------->| | (200 OK SUBS)| Update PSTN elements |<----------------------------+ | F2 (NOT) | |<----------------------------+ Accept the subscription; |(200 OK NOT) | send base notification +---------------------------->| | F3 (NOT) | |<----------------------------+ Send base PIDF document |(200 OK NOT) | +---------------------------->| | | = = | | | | Event of interest occurs | F4 (NOT) | Send NOTIFY containing DP |<----------------------------+ |(200 OK NOT) | +---------------------------->| | F5 (NOT) | |<----------------------------+ Send delta PIDF document |(200 OK NOT) | +---------------------------->| | | \/ \/ F1 SUBSCRIBE sip:192.168.1.2:9001 SIP/2.0 Via: SIP/2.0/TCP 192.168.1.1;branch=z9hG4bK1.0239881922202132 To: From: ;tag=6738688359992660166 CSeq: 472596 SUBSCRIBE Call-ID: 5945339689215500186@192.168.1.1 Event: spirits-INDPs Allow: SUBSCRIBE, NOTIFY Accept: application/spirits-event, application/cpim-pidf+xml Contact: Content-Type: application/spirits-event Content-Length: 462 5552207722 draft-gurbani-spirits-implementation-00.txt [Page 4] Early implementation of the SPIRITS protocol February 2003 5552207722 5552207722 5552207722 This SIP request contains a SPIRITS payload that identifies the DPs required to detect a coarse-grained form of presence on a device (phone). The DPs are: Termination Answer (TA), Termination Disconnect (TD) on the Terminating Basic Call State Model (T_BCSM) side; Origination Attempt Authorized (OAA), and Origination Disconnect (OD) on the Originating Basic Call State Model (O_BCSM) side. Whenever a DP from this set is triggered, the SPIRITS client (notifier) will send a NOTIFY request to the SPIRITS server (subscriber). Of interest is also the MIME types that appear in the "Accept" header of the SUBSCRIBE. The subscriber UA accepts two MIME types: SPIRITS payload, and a Presence Information Data Format (PIDF) document. Thus, when a DP from the above set is triggered, a NOTIFY corresponding to it will be sent (F3); in addition, another NOTIFY (F4) will also be sent which includes a PIDF document for presence purposes. Note that we could have send two SUBSCRIBE requests; one corresponding to the SPIRITS DPs (Event: spirits-INDPs) and the other corresponding to presence-related events (Event: presence) [7]. Instead, in this example implementation, we have chosen to denote the presence aspect by including the appropriate Accept header MIME type (application/cpim-pidf+xml). F2 NOTIFY sip:192.168.1.1:9090 SIP/2.0 To: ;tag=6738688359992660166 From: ;tag=--*befb@@ Call-ID: 5945339689215500186@192.168.1.1 CSeq: 9323 NOTIFY Via: SIP/2.0/TCP 192.168.1.2:9001;branch=z9hG4bK3e554116 Contact: Subscription-State: active Content-Length: 0 A base NOTIFY is sent to the subscriber accepting the subscription. F3 NOTIFY sip:192.168.1.1:9090 SIP/2.0 To: ;tag=6738688359992660166 From: ;tag=--*befb@@ Call-ID: 5945339689215500186@192.168.1.1 CSeq: 9324 NOTIFY draft-gurbani-spirits-implementation-00.txt [Page 5] Early implementation of the SPIRITS protocol February 2003 Via: SIP/2.0/TCP 192.168.1.2:9001;branch=z9hG4bK3e5540fa Contact: Content-Type: application/cpim-pidf+xml Subscription-State: active Content-Length: 387 CLOSED Unavailable sip:5552207722@lucent.com A NOTIFY containing the PIDF document is then sent to the subscriber. This NOTIFY request initializes the presence state of the device (Unavailable). We deliberately chose the initial presence state to be Unavailable due to security and privacy reasons. F4 NOTIFY sip:192.168.1.1:9090 SIP/2.0 To: ;tag=6738688359992660166 From: ;tag=--*befb@@ Call-ID: 5945339689215500186@192.168.1.1 CSeq: 9325 NOTIFY Via: SIP/2.0/TCP 192.168.1.2:9001;branch=z9hG4bK3e4891aab Contact: Content-Type: application/spirits-event Subscription-State: active Content-Length: 223 5552207722 5552202040 This NOTIFY is sent out because an event of interest (OAA) was detected by the SPIRITS client. As per the SPIRITS protocol, all the relevant information is collated and send as a SPIRITS payload. F5 NOTIFY sip:192.168.1.1:9090 SIP/2.0 To: ;tag=6738688359992660166 From: ;tag=--*befb@@ Call-ID: 5945339689215500186@192.168.1.1 CSeq: 9326 NOTIFY draft-gurbani-spirits-implementation-00.txt [Page 6] Early implementation of the SPIRITS protocol February 2003 Via: SIP/2.0/TCP 192.168.1.2:9001;branch=z9hG4bKuu71aa26 Contact: Content-Type: application/cpim-pidf+xml Subscription-State: active Content-Length: 416 CLOSED In a call since Thu Feb 20 14:56:54 2003 sip:5552207722@lucent.com This NOTIFY is sent out to watchers to update the presence status of the device. To that extent, it contains a PIDF document with a local XML namespace extension (local) which further quantifies the element. The element imparts service provider specific information which may be displayed in the UI of the SPIRITS subscriber UA. In this case, we opted to send the presence status of the user as being busy since a certain time. There is no reason why additional informational elements such as the caller's phone number cannot be displayed (in fact, this information is already available through the NOTIFY in F4; however, we chose not to provide it as a display element in the UI). 4.2 Instant Message In this service, a subscriber is interested in monitoring a certain phone line. For example, this line could represent the subscriber's home line which she would like to monitor from her work. As soon as a call arrives at the line, she would like the PSTN to send an IM to her UA, whereupon she can decide if she would like to return the call immediately. The call flow is presented next followed by a message analysis. SPIRITS server SPIRITS client (subscriber) (nofitier) 192.168.1.1 192.168.1.2 |F1 (SUBS) | +---------------------------->| | (200 OK SUBS)| Update PSTN elements |<----------------------------+ | F2 (NOT) | |<----------------------------+ Accept the subscription; |(200 OK NOT) | send base notification draft-gurbani-spirits-implementation-00.txt [Page 7] Early implementation of the SPIRITS protocol February 2003 +---------------------------->| | | = = | | | | Event of interest occurs | F3 (NOT) | Send NOTIFY containing DP |<----------------------------+ |(200 OK NOT) | +---------------------------->| | F4 (MSG) | |<----------------------------+ Send the IM |(200 OK MSG) | +---------------------------->| | | \/ F1 SUBSCRIBE sip:192.168.1.2:9001 SIP/2.0 Via: SIP/2.0/TCP 192.168.1.1;branch=z9hG4bK0.577242217883416 To: From: ;tag=-976415514390200217 CSeq: 65037 SUBSCRIBE Call-ID: -6299696320093323677@192.168.1.1 Allow: SUBSCRIBE, NOTIFY, MESSAGE Accept: application/spirits-event, text/plain Contact: Content-Type: application/spirits-event Content-Length: 154 5552202040 Here, a Termination Attempt Authorized (TAA) is set on a line. This DP is encountered and is triggered on the terminating side when an incoming call arrives for the line. Note that the "Allow" header contains 3 SIP methods that are supported by this UA: SUBSCRIBE, NOTIFY, and MESSAGE. Thus, the SPIRITS client (notifier) knows that the subscriber can accept MESSAGE requests. This is further re-inforced by the presence of the MIME type "text/plain" in the "Accept" header. F2 NOTIFY sip:sip:192.168.1.1:9091 SIP/2.0 To: ;tag=-976415514390200217 From: ;tag=--*bf07@@ Call-ID: -6299696320093323677@192.168.1.1 CSeq: 9321 NOTIFY Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bK9aas6794 Contact: draft-gurbani-spirits-implementation-00.txt [Page 8] Early implementation of the SPIRITS protocol February 2003 Subscription-State: active Content-Length: 0 Subscription is accepted and a base NOTIFY request is sent out. F3 NOTIFY sip:sip:192.168.1.1:9091 SIP/2.0 To: ;tag=-976415514390200217 From: ;tag=--*bf07@@ Call-ID: -6299696320093323677@192.168.1.1 CSeq: 9322 NOTIFY Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bK3e555644 Contact: Content-Type: application/spirits-event Subscription-State: active Content-Length: 223 5552202040 5552207722 When a call arrives for the line, a NOTIFY is sent to the subscriber, followed immediately by a MESSAGE request. F4 MESSAGE sip:sip:192.168.1.1:9091 SIP/2.0 To: ;tag=-976415514390200217 From: ;tag=--*bf07@@ Call-ID: -6299696320093323677@192.168.1.1 CSeq: 9322 MESSAGE Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bK89asd678 Contact: Content-Type: text/plain Content-Length: 86 From PSTN buddy: Phone call from 5552207722 to 5552202040 at Thu Feb 20 16:27:16 2003 The body of the MESSAGE request contains a plain text formatted message which is displayed in the appropriate window of the SPIRITS subscriber's UA. ACKNOWLEDGMENTS The authors would like to acknowledge Alec Brusilovsky, Jack Kozik, William O'Keefe, Doug Varney, and Cindy Yao, for their support and input to the early implementation. AUTHORS' ADDRESSES draft-gurbani-spirits-implementation-00.txt [Page 9] Early implementation of the SPIRITS protocol February 2003 Vijay K. Gurbani 2000 Lucent Lane Rm 6G-440 Naperville, IL 60566 USA Email: vkg@lucent.com Sudha Gouthama 1960 Lucent Lane Rm 9B-530 Naperville, IL 60566 Email: gouthama@lucent.com Byron J. Williams 1960 Lucent Lane Rm 9B-522 Naperville, IL 60566 Email: bjw@lucent.com ACRONYMS CPIM Common Presence and Instant Messaging DP Detection Point IM Instant Message IN Intelligent Network IP Internet Protocol MIME Multipurpose Internet Mail Extensions O_BCSM Originating Basic Call State Model PIDF Presence Information Data Format PSTN Public Switched Telephone Network SCF Service Control Function SIP Session Initiation Protocol SPIRITS Services in the PSTN/IN Requesting InTernet Services SSP Service Switching Point T_BCSM Terminating Basic Call State Model Normative references [1] Vijay K. Gurbani (Ed.), Alec Brusilovsky, Igor Faynberg, Hui-Lan Lu, Musa Unmehopa, Kumar Vemuri, and Jorge Gato, "The SPIRITS (Services in PSTN requesting Internet services) Protocol", Internet-Draft, Work in progress, expires May 2003, [2] Lev Slutsman (Ed.), Igor Faynberg, Hui-Lan Lu, and Mark Weissman, "The SPIRITS Architecture", IETF RFC 3136, June 2001, [3] Igor Faynberg (Ed.), Jorge Gato, Hui-Lan Lu, and Lev Slutsman, "Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements", IETF RFC 3298, August 2002, draft-gurbani-spirits-implementation-00.txt [Page 10] Early implementation of the SPIRITS protocol February 2003 [4] Hiroyasu Sugano, Shingo Fujimoto, Graham Klyne, Adrian Bateman, Wayne Carr, and Jon Peterson, "Common Presence and Instant Messaging (CPIM) Presence Information Data Format", IETF Internet-Draft, Work in progress, expires June 2003, Informative references [5] Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo, Alan Johnston, Jon Peterson, Robert Sparks, Mark Handley, and Eve Schooler, "The Session Initiation Protocol (SIP)", IETF RFC 3261, June 2002, . [6] Adam Roach, "Session Initiation Protocol (SIP)-Specific Event Notification", IETF RFC 3265, June 2002, [7] Jonathan Rosenberg, "A Presence Event Package for the Session Initiation Protocol (SIP)" IETF Internet-Draft, Work in progress, expires July 2003, [8] Ben Campbell (Ed.), Jonathan Rosenberg, Henning Schulzrinne, Christian Huitema, and David Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", IETF RFC 3248, December 2002, 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 draft-gurbani-spirits-implementation-00.txt [Page 11] Early implementation of the SPIRITS protocol February 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. draft-gurbani-spirits-implementation-00.txt [Page 12]