Internet Draft Toward Definition Of the SPIRITS Architecture: SPIRITS Interfaces [Page 1] SPIRITS Working Group L. Slutsman Expires: September 2000 AT&T Labs Toward Definition Of the SPIRITS Architecture: SPIRITS Interfaces <draft-lslutsman-spirits-interfaces-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 The SPIRITS physical architecture and the relevant background explanation of the mechanism for interactions between the PSTN and SPIRITS are provided in [1]. This document is attempted to take a next step and to describe all the SPIRITS interfaces necessary to support the following services defined in the WG charter: Internet Call Waiting (the leading SPIRITS benchmark service), Internet Caller-ID Delivery, and Internet Call Forwarding. The end-to-end implementation of charter services will require cooperation with ITU-T on the total protocol development. To this end this draft raises the discussion of the "ownership" of protocols per SPIRIT interface. 1. Introduction The SPIRITS physical architecture and the relevant background explanation of the mechanism for interactions between the PSTN and SPIRITS are provided in [1]. This document is attempted to take a next step and to describe all the SPIRITS interfaces necessary toMarch 2000 Toward Definition Of the SPIRITS Architecture: SPIRITS Interfaces [Page 2] support the following services defined in the WG charter: Internet Call Waiting (the leading SPIRITS benchmark service), Internet Caller-ID Delivery, and Internet Call Forwarding. The end-to-end implementation of charter services will require cooperation with ITU-T on the total protocol development. To this end this draft raises the discussion of the "ownership" of protocols per SPIRIT interface. The format of the rest of this paper is as follows Section 2 Describes the relevant interfaces; Section 3 Contains acknowledgements; Section 4 contains references; Section 5 contains the author address; and Appendix contains Figure 1. 2. SPITIS Interfaces. The simplified SPIRITS "physical" architecture and interfaces are depicted in Figure 1 of the Appendix. The Central Office in the picture is the PSTN switch that fires the query to the SPIRITS Client which starts a SPIRIT service. Specifically for Lucent implementation of ICW [3], the Central Office serves as am end user--terminating LEC, but it does not have to act as such in general. The SPRITS server (probably the better name would be SPIRITS proxy) serves three functions: 1)it receiver and executes the PSTN request, which along with the information available in the trigger, arrives on interface "A"; 2) it returns, if necessary, the outcome of the IP service execution back to the SPIRITS Client over interface "B"; and 3)communicates with the end-user (acting as a client) over interface "C. The interfaces "E" and "D" are used to accomplish the PSTN telephony functions. The rest of the Section 2, will describe in detail each of interfaces mentioned above. 2.1 Interface "A" . The SPIRITS services are invoked when a message from a SPIRIT Client (located in the IN Service Control Point [SCP] or Service Node [SN]) arrives on interface "A" to the SPIRITS Server over the IP network. In most practically important cases, the request from the SPIRITS client is caused by a request/query from a Central Office sent to the SPIRITS server (that is either by the SCP or the SN). The request is sent when the switch call process approaches the SPIRITS "significant" trigger, such as Termination Attempt Trigger (TAT). The SPIRITS server may need to know the specific conditions/parameters that had been detected at the trigger .These information is the parth of the payload of the request message. For the important case of TAT, the message parameters are detailed in [1]. The most important for the ICW service are "Call ID" (a March 2000 Toward Definition Of the SPIRITS Architecture: SPIRITS Interfaces [Page 3] mandatory parameters, which specifies the PSTN CALL), and "Alerting Pattern" (an optional parameter specifying how to "ring" the end user). Thus for ICW, it may be desirable to use the PC for "ringing" rather than applying the ringing tone to its line, in order not to interface with standard telephony services such as Call Waiting. The corresponding protocol is very likely the responsibility of the ITU-T; however, the interface agreement should be worked jointly and provide, at least, : Detail description of parameters for each While the protocol used to send the message is not the domain of the SPIRITS WG, the information that arrives with the message is important. ¹ SPIRITS trigger. ¹ Instructions how SPIRITS server should proceed upon completion of its portion of service (for example, if the SPIRITS client expects the SPIRITS server to response with specific actions (e.g. jump to a specific PIC into the BCSM on the Central Office). 2.2 Interface "B" This interface is used to deliver a message from the SPIRITS server to a SPIRITS client. For example, the switch call process may be suspended in the trigger, waiting for the response from the SCP/SN to resume; the SCP may, in turn, be waiting for the SPIRITS server to response. The SPIRITS client can solicit this response in the original request message as was mentioned above, or the SPIRITS client could figure out the need for such response from the nature of the service request. In another scenario, after the initial interaction between the SPIRITS client and the SPIRITS server takes place, the latter , based on the dynamic of the execution of IP portion of the service, can requestt the SPIRITS client to arm additional detection points (DPs) in the Central Office BCSM for the duration of the call. The SPIRITS client will have to send appropriate messages to the Central Office (for the SCP-base implementation) or to enable appropriate internal events (in an implementation-depend ent manner) in the SN (for the SN-based implementations). As messages on the interface "B" are generated within the SPRITS server, the corresponding protocol is a potential candidate for the SPIRITS WG, or the joint development with ITU-T. 2.3 Interface "C" This interface is used to communicate information between the SPIRITS server and an end-user PC in both directions. For example in the Lucent ICW scenario, upon establishing the PPP connection with the ISP, the end-user PC software will inform the SPRITITS server the voice line is used for the Internet. Upon arriving an subsequent incoming voice call , the SPIRITS server will request the end user to make a choice: (e.g. drop the modem , direct the incoming call to the voice mail . The end user will send his choice back to the SPIRITS services. In addition, his interface may be used for authentication and service provisioning. The corresponding protocol is the responsibility of the WG. March 2000 Toward Definition Of the SPIRITS Architecture: SPIRITS Interfaces [Page 4] 2.4 Interface "E", and "D" Interface "D" stands for the SS7 signaling between the central Office and the SPIRITS client. Interface "E" provides the PSTN connectivity via a loop, trunk, cable, etc. Both interfaces are outside the scope of WG and mentioned here for the sake of completeness. 3. Acknowledgements We would like to thank I. Faynberg and A. Brusilovsky for their comments and input. 4. References [1] I. Faynberg, H. Lu , M. Weissman, and L. Slutsman, "Towards Definition of the Protocol for PSTN-initiated Services Supported by PSTN/Internet Interworking", IETF draft, expires Septemeber 2000. [2] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent Network Standards: Their Application to Services," McGraw-Hill, 1997. [3] I.Faynberg, H.Lu,, and other. "On a pre-SPIRITS Implementation in the Lucent Technologies Online Communications Center", IETF draft, expires September 2000. 5. Author's Addresses: Lev Slutsman AT&T Labs Room D5-3D26 200 Laurel Avenue S, Middletown, NJ, USA 07748 Lslutsman@att.com 732-420-3756 Appendix Figure 1. SPIRITS Interface Architecture |----------| |---------|/____A_____| | |SPIRITS |/_____C_____\ |SPIRITS |\ | SPRITS Client | |EndUser PC|\ / |SERVER |_____B____\| (SCP/SN) | |----------| |---------| /|______________ | | EndUser | E |------| | | Telephone|--------------|PSTN | E |--------------| |D |----------| |Cloud |------|CENTRAL OFFICE|---| |------| |--------------| March 2000 Toward Definition Of the SPIRITS Architecture: SPIRITS Interfaces [Page 5] March 2000