Internet Draft Internet Draft I.Faynberg draft-ietf-spirits-protocol-00.txt H. Lu March 2000 M. Weissman Expires September 2000 Lucent Technologies L. Slutsman AT&T Labs Toward Definition of the Protocol for PSTN-initiated Services Supported by PSTN/Internet Interworking 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 1) Provides the relevant background explaining the mechanism for interactions between the PSTN and SPIRITS Server 2) Based on this mechanism, provides basic requirements and sets forth the methodology for constructing the building blocks of the SPIRITS protocol. 3) Provides particular examples of application of this methodology regarding the leading SPIRITS benchmark service--the Internet Call Waiting (ICW). As such, this document contributes to the future SPIRITS architecture and protocol RFCs. 1. Introduction This document Toward SPIRITS Protocol Definition November 1999 SPIRITS [Page 2] 1) Provides the relevant background explaining the mechanism for interactions between the PSTN and SPIRITS Server 2) Based on this mechanism, provides basic requirements and sets forth the methodology for constructing the building blocks of the SPIRITS protocol. 3) Provides particular examples of application of this methodology regarding the leading SPIRITS benchmark service--the Internet Call Waiting (ICW). As such, this document contributes to the future SPIRITS architecture and protocol RFCs. The rest of this Internet Draft is as follows: Section II describes the relevant physical architecture; Section III emphasizes the role of the IN call model; Section IV proposes the methodology and considers examples; Section V contains the acknowledgements; Section VI contains references; and Appendix contains Figure 1. 2. Physical Architecture Figure 1 of the Appendix depicts the joint PSTN/Internet physical architecture relevant to SPIRITS. The services are invoked (and, subsequently, the SPIRITS protocol is initiated) when a message from a SPIRIT Client (located in the IN Service Control Point [SCP] or Service Node [SN]) arrives (either, on interface E or A, respectively) to the SPIRITS Server. Both E and A interfaces are over the IP network (very likely, over the Internet). The SPIRITS Server has access to PCs and network appliances over the Internet. Its function may in fact be implemented at these end-points; it may, alternatively, be implemented on the same machines that run the SN and SCP software; finally, it may be implemented on a stand-alone machine, which is the most general case and is thus depicted in Figure 1. In most practically important cases, the request from a SPIRITS client is caused by a request from a Central Office (i.e., a telephone switch) sent to either the SCP or SN, although the Internet-based service initiation by these elements that had not been triggered by the Central Office is theoretically possible. Definitely, none of the SPIRITS benchmark services are initiated in such a way, so for the purposes of the SPIRITS protocol development, it should be assumed that the service invocation was a direct result of an earlier action by the Central Office. Toward SPIRITS Protocol Definition November 1999 SPIRITS [Page 3] Note that the "or" in "SCP or SN" is exclusive: When the Central Office realizes that an external action is needed it either proceeds with issuing a query to the SCP (to which it has no bearer circuit connection, only a signaling one [over Signaling System No.7]) or forwards the call to the SN (to which it has the ISDN connection). The SCP and SN are described in the ITU-T Recommendations Q.1205, Q.1215, and Q.1225, as well as in Chap. 6 of reference [1]. It should also be noted that present SN implementations may contain both the Signaling System No. 7 and ISDN access interfaces, so that such SNs may act as pure SCPs. Still for the purposes of a particular SPIRITS service instance, the SN would act either as an SCP or "original SN." Note that the architecture excludes direct communications of the Central Office with the SPIRITS server. Such communications can be achieved only by means of either the SCP or SN. Moreover, as far as SPIRITS is concerned, there MUST be no difference in the protocol whether the connection is with the SCP or SN on the PSTN side. 3. The role of the IN Call Model The Central Office determines that it needs an external action based on its call model (which does not necessarily have to be the IN call model). If the Central Office does not use the IN means directly, it may establish a circuit to the SN; the latter then picks up the IN processing. Alternatively, if the Central Office does use the IN Basic Call State Model (BCSM), it may issue the request to the SCP when the external processing is needed. BCSM is standardized in the ITU-T Recommendation Q.1204 (general aspects), Q.1214 (IN Capability Set 1 aspects), and Q.1224 (IN Capability Set 2 aspects); Chap. 5 of [1] also discusses the development of the concept. The model guides all the aspects of the service request initation. Because neither the "internal" call models (i.e., the ones that support switch-based services) nor the internal SN interfaces (i.e., interfaces between the call processing and service processing) are standardized, the SPIRITS protocol can be influenced normatively only by the BCSM and the protocol, Intelligent Network Application Part (INAP), which accompanies it. (The respective general, IN Capability Set 1, IN Capability Set 2, and tutorial references are ITU-T Recommendations Q.1208, Q.1218, and Q.1228; and Chap. 6 of [1]. A recent Internet Draft [2] describes in detail the general IN BCSM. Of course, neither the BCSM, nor INAP are subject to standardization in SPIRITS; however, both have direct influence on SPIRITS inasmuch as the former effectively defines the service initiation events and the corresponding minimum set of messages that are initially issued by the SPIRITS Client and the latter defines what information is available at the SPIRITS client at the time the service is initiated. In fact, as we will soon demonstrate, the same set of events can re- occure later in the service, and, consequently same messages can be Toward SPIRITS Protocol Definition November 1999 SPIRITS [Page 4] sent in the middle of the service-supporting exchange. The BCSM specifies two finite state machines: one for the originating, and one for the terminating part of the call. In addition to a call state (called Point in Call [PIC]), each part also specifies special states called Detection Points (DPs) that are associated with the transitions between PICs. The PICs are best viewed as "primary" states in that DPs are directly associated with the transitions from PIC to PIC. Thus, the basic construct of the BCSM is PIC-->DP-->PIC, although non-DP-associated transitions (i.e., PIC-->PIC) also exist. If a transition passes through a DP, the Central Office pauses and examines 1) whether a DP is armed (i.e., active) and 2) whether it meets the criteria for launching an IN query or sending a notification. If a DP is armed (off-line) from the Service Management System (SMS), it is called a trigger. The trigger is static in that it is armed "forever." All Spirits services are initiated by triggers. But the same DPs that can be set "off-line" as triggers can also be set "on line"--for the duration of a paricular call and only for that call--by the SCP. Regardless of whether they are armed statically or dynamically, DPs can be armed either as notifications or requests. Correspondingly, depending on the type of the active DP, the Central Office can either issue a notification (and transit to the next PIC) or, suspend call processing, issue a request to the SCP, and wait for the response. When the response comes back, it may contain an instruction on how to continue with the call. (Such an instruction may even "break" the model by causing a "go-to"-type transition to any other PIC.) The use of SMS can sometimes be avoided by implementing its service distribution and trigger-setting function by other means. The SMS thus is included here for completeness. On the PSTN side, the purposes of the Internet Call Waiting (ICW) can be met with one of the two approaches--one based on the SN, and one on the BCSM-to-Service Control (i.e., Central Office-to-SCP) interaction. With the SN-based approach, when the Central Office detects that the called party is busy, it simply forwards the call to the SN, whose service logic initiates the message exchange by sending the notification to the SPIRITS server. With the SCP-based approach, the Central Office can use either of the two DPs of the Terminating BCSM: "Termination Attempt Authorized" or busy. (Either DP, of course, would need to be armed as trigger.) Nevertheless, the SPIRITS server MUST see the same notification, independent of the approach. Once the interactions between the SPIRITS client and SPIRITS server started, the latter can instruct the client to arm additional DPs for the duration of the call. The client, could, in turn, send appropriate messages to the Central Office (for the SCP-based implementation) or enable appropriate internal events (in an implementation-dependent manner) in the SN (for the SN-based implementations). Toward SPIRITS Protocol Definition November 1999 SPIRITS [Page 5] This discussion supports the methodology proposal of the following section. 4. Methodology To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set of messages), the PSTN events associated with each detection point of the Basic Call State Model should be examined. To date, the CS-2 BSCM has the richest set of DPs, although not all switching exchanges have implemented it. To determine the MINIMUM information available to the SPIRITS client (this information is to be carried by the SPIRITS protocol from SPIRITS client to SPIRITS server), each DP-specific information elements needs to be examined. For example, with the CS-2 Termination Attempt Authorized, the following maximum set of information elements (because all parameters but the first one are optional) is available, and the following decisions can be made when analyzing it: 'Call ID' (a mandatory information element, which defines the PSTN call, and should be used unchanged) 'Alerting Pattern' (an optional informational element specifiying how to ring the user. If available, could be used for "cute" embellishment, such as using the multimedia PC capabilities to "ring" the user in the same pattern.) 'Backward GVNS' (an optional information element concerning the PSTN Virtual Private Network [GVNS stands for Global Virtual Network Service] implementation, which is hardly meaningful for the present ICW means) 'Calling Party Number' (an optional--alas--informational element, which is obviously quite useful) 'Destination Routing Address' (an optional information element, which is defined somewhat ambigously and needs further investigation) 'Display Information' (an optional information element that specifies the information to be displayed to the ISDN terminal user. Naturally, highly relevant.) 'Forward GVNS' (to be disposed of in the same way as Backward GVNS) 'IN Service Compatibility Response' (something to be used only by PSTN) Toward SPIRITS Protocol Definition November 1999 SPIRITS [Page 6] 'ISDN Access Related Information' (another thing to be used only by PSTN) 'Leg ID To Be Created' (an optional parameter irrelevant to ICW) 'Original Called Party ID' (an optional parameter, which contains the first number dialed by the user. Could be used in a creative embellishment.) 'SCF ID' (an optional parameter, which is seemingly of no use.) 'Service Interaction Indicators' (an optional parameter, with many values-- definitely needs more study.) 'Travelling Class Mark' (an optional parameter irrelevant to ICW.) 5. Acknowledgements We would like to thank Walid Abouhamad and Buddy Bright for both supplying us with the essential information and then providing incisive comments on the draft. We thank Kumar Vemuri for a careful review and interesting discussion of this draft. Thanks also go to Steve Bellovin, A.Brusilovsky, J. Buller, L. Conroy, D. Oran, V. Paxson, S. Petrack, Henry Sinnreich and all other PIN BOF participants for the on-line and oral input to the discussion that shaped the foundations of SPIRITS. 6. References [1] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent Network Standards: Their Application to Services," McGraw-Hill, 1997. [2] Gurbani, V., Accessing IN services from SIP networks. draft-gurbani-iptel-sip-to-in-00.txt, expires December 1999. Toward SPIRITS Protocol Definition November 1999 SPIRITS [Page 7] 7. Appendix Figure 1: SPIRITS Physical Architecture ------------------------- | PC or Network Appliance | ------------------------- | ------------ O -------------------------- | Internet |----------------------- ------------ | | ---------------- -------------- --------------- | Service Node | D | Service | B | SPIRITS | | (SN) |------------| Management |------------------| Server | | | |System (SMS)| | | | SPIRITS | ------------ | | | Client | : A | | |______________|-------[ IP Network]------------------------|_____________| | : | | C : H E [IP Network] | ........................ | -------- G -------- |Central|-----------------------------------------|Service| |Office | |Control| --------- |Point | | (SCP) | | | |SPIRITS| |CLIENT | --------- 8. Author's Addresses Igor Faynberg Lucent Technologies Room 4L-334 101 Crawfords Corner Road Holmdel, NJ 07733-3030 US E-mail: faynberg@lucent.com Telephone: +1 732 949 0137 Hui-Lan Lu Lucent Technologies Room 4L-317 101 Crawfords Corner Road Holmdel, NJ 07733-3030 US E-mail: huilanlu@lucent.com Telephone: +1 732 949 0321 Mark Weissman Lucent Technologies SUITE 500 2000 Regency Pky Cary, NC 27511-8506 US Toward SPIRITS Protocol Definition November 1999 SPIRITS [Page 8] E-mail: maw1@lucent.com Telephone: +1 919 380 6813 Lev Slutsman AT&T Labs Room D5-3D26 200 Laurel Avenue S, Middletown, NJ 07748 US E-mail: lslutsman@att.com Telephone: +1 732 420 3756 Toward SPIRITS Protocol Definition November 1999