Network Working Group I. Faynberg Internet Draft Lucent Technologies draft-faynberg-spirits-inpintreqs-01.txt> J. Gato Expires April 2001 Airtel Movil H. Lu Lucent Technologies L. Slutsman AT&T IN- and PINT-related Requirements for SPIRITS Protocol Status of this Memo This document is an Internet-Draft and is in full conformance wit all provisions of Section 10 of RFC2026. This document outlines a proposal to the IETF for a new work item in support of service delivery in converging networks. 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. 1. Abstract This Internet-Draft is written in response to the SPIRITS WG chairs' call for contributions to the future RFC on the SPIRITS protocol requirements. The goal of this document is to introduce the requirements pertinent to Intelligent Network (IN) and the (future) work of PSTN/Internet iNTernetworking (PINT) WG. To this end, the SPIRITS architecture has been slightly augmented to demonstrate the relation of PINT to SPIRITS as discussed at the Adelaide meeting. 2. Conventions used in this document In examples, "C:", "P", and "S:" indicate lines sent by the client, Proxy, and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman July 2000 [Page 2] Unless otherwise qualified, the term PINT is used here not to refer to the present PINT services and protocol, but in reference to the scope of the generic PINT (vs. SPIRITS) service characteristic--being invoked from an IP network (vs. PSTN). 3. Introduction The joint PINT/SPIRITS architecture (described in [1]) is depicted in Figure 1. It is assumed that the Spirits Client is either co-located with the IN Service Control Function (SCF) or communicates with it (over the PSTN-specific interface D) in such a way so as to act on behalf of the PSTN/IN. (This assumption is confirmed by current implementations, as reported in [2].) The SPIRITS services are invoked (and, subsequently, the SPIRITS protocol is initiated) when a message from a SPIRITS Client (located in the IN Service Control Point [SCP] or Service Node [SN]) arrives on interface C to the SPIRITS Proxy. The Spirits Proxy processes the message and, in turn, passes it on over the Interface B to the SPIRITS server. In most practically important cases, the request from a SPIRITS client is ultimately 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.) IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman July 2000 [Page 3] Subscriber's IP Network IP Host _______________ .................... | _____________ | A . ________________ . | |PINT Client|*******| PINT Server |******** | |___________| | . |______________| . * | ____________ | . * . * | | SPIRITS | | B . _______*________ . * | | Server |*******|SPIRITS Proxy | . * | |___________| | . |______________| . * |_______________| .........*.......... * *C * _________________ ______*________ * | Subscriber | |SPIRITS Client | * | Telephone | | * |_________________| |_______________| * * * * E * Line * D * ++++++++++*+++++++++++PSTN+++++*+++++++++++++++*++ * * * +----------------+ +------------------------+ | SSP(Switch) |*****| SERVICE CONTROL | +----------------+ SS7 +------------------------+ Figure 1. Joint PINT/SPIRITS Architecture With PINT (and that also applies to the present PINT architecture and protocol as described in [3], the service request to the PINT Server is always initiated by the PINT Client over the interface A. The PINT Server can either be co-located with the IN Service Control or a similar entity (referred to as "Executive System" by [3]) or communicate with it over the PSTN-specific interface E. As Figure 1 shows, the PINT Client and SPIRITS Server are co-located in Subscriber's IP Host. In fact, both can be implemented to run as one process. No provision is made for interactions between the PINT Client and Spirits Server. Similarly, the PINT Server and SPIRITS Proxy are assumed to be co-located, too. This assumption is convenient but not essential; the PINT Server could also be co- located with the SPIRITS Client. In either case, no specific provision is made to define interworking between either the PINT Server and Spirits Proxy or PINT Server and SPIRITS Client other then by listing the overall PINT-related requirements. The rest of this Internet-Draft addresses the IN Requirements, PINT Requirements, the protocol development methodology, and security issues, in that order. 4. IN Requirements IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman July 2000 [Page 4] The interface immediately relevant to IN is that between the SPIRITS Client and SPIRITS Proxy (interface C). A typical message (which starts a SPIRITS service) looks like that: C -> P: , The relevant events correspond to the detection points (DPs) of the IN Basic Call State Model (BCSM). The is a function of a specific DP; it contains the parameters relevant to it. The following requirements apply: 1) The list of the DPs to be covered encompasses those defined in the IN Capability Set 3 BCSM as well as those that relate to the Wireless IN (WIN) specified by the IMT 2000 project in ITU-T. 2) Not all parameters associated with such DPs are needed by the SPIRITS benchmark services, nor may all the parameters be needed in SPIRITS. The selection of the relevant parameters is part of the SPIRITS protocol definition. 3) It is desirable to avoid semantic overload of protocol messages. (One way to achieve that is to match each event with a message that corresponds to it.) In case the SPIRITS protocol is designed as a set of extensions to another (existing) protocol with the defined message set, the syntax and semantics of the extensions should be defined with this requirement in mind. 4) The ITU-T Recommendations use the abstract syntax notation (ASN.1) to specify the semantics of the IN Application Protocol (INAP) parameters, which are expected to be binary-encoded Neither the use of the ASN.1, nor the requirement for binary encoding are the typical requirements for the IETF application protocols. Recognizing that, provisions must be made for careful specification of the conversion of the INAP parameters to text, which must preserve their original semantics. The actual conversion of the parameters is the function of the SPIRITS Client. In order to issue an initial query (or a notification) to service control, a switch must have such a DP set. This can be done statically via service management (this particular action should be left to implementation and thus is considered outside of the scope of SPIRITS Protocol) or dynamically--but only for the purpose of a particular call--from the service control. In the latter case, it is part of the SPIRITS (or PINT) protocol to request the event notification from the service control. This function can be performed by either the Spirits Client or PINT Server, the distinction being further discussed in the next section. Assuming that it is performed by the SPIRITS Client, the relevant message should look like C: SUBSCRIBE , where refers to a particular DP; determines whether the Event Detection Point (EDP) is to be armed as EDP Request (EDP- R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is not IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman July 2000 [Page 5] foreseen); and the is the list of the values of the parameters associated with the EDP (for example, if the DP in question is O_No_Answer, then the value of the appropriate timer should be included in the list). Note that such a subscription may also originate at a) PINT Client or b) SPIRITS Proxy, either of which may (but does not have to) have a locally significant definition of the . In either case, it is the function of the SPIRITS Client to translate the definition of the Event into a particular DP (or set of DPs) when passing the message to Service Control. To summarize, for the case when PINT and SPIRITS events are defined in a way where they do not refer to the BCSM DPs, it is the function of the SPIRITS Client to define a mapping: Event -> DP List, for each event for which the PSTN notification is needed. The list of CS-2 DPs envisioned in SPIRITS is - origination_attempt_authorized (the SPIRITS service can control call attempts, (for example, to limit calls during specific time periods) - collected_information and analyzed_information (for SPIRITS outgoing call screening) - o_answer, o_term_seized, and t-answer (to release SPIRITS resources after the call is complete) - o_no_answer, route_select_failure, and t_no_answer (to re-route a call) - o_busy (to re-route a call and for Internet Call Waiting) - o_mid_call and t_mid_call (to assist a midcall action) - o_abandon, o_disconnect, t_abandon, and t_disconnect (to terminate a SPIRITS service and release the resources With that, the only DPs needed to implement the present SPIRITS milestone services are - termination_attempt_authorized (needed for SPIRITS "milestone" services) - facility_selected_and_available (could be used in SPIRITS Internet Caller-ID) - t_busy (for Internet Call Waiting and Call Forwarding). 5. PINT-related Requirements IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman July 2000 [Page 6] Before a SPIRITS service can be invoked, the relevant IP Host must be registered. Thus, Registration is an essential service (not yet addressed by PINT), which is initiated from the IP side. The registration information is ultimately used by the PSTN to authenticate the subscriber. Depending on the model, this can be done in two ways with the present architecture: 1) The PINT Client issues the appropriate Register message over the interface A, which is then passed to by PINT server to the SPIRITS Proxy and SPIRITS Client: PINT C.: -- REGISTER --> PINT S. [--> SPIRITS Proxy --> SPIRITS C.]. In this case the SPIRITS Client (co-located with the service control) is responsible for record keeping and the authentication. 2) The PINT Client issues the appropriate Register message to the PINT Server, which then passes this information to the PSTN service control "by magic". The second model is much easier to handle, because it involves only one relevant interface ("A"); however it assumes no interworking between PINT and SPIRITS except that the SPIRITS Client finds "by magic" that a friendly and expecting IP Host is alive and well. As noted in previous section, the existing SUBSCRIBE/NOTIFY PINT building blocks must be extended for their use in SPIRITS for the purposes of setting DPs/getting DP event notifications. Conversely, the same building blocks for this functional capabilities can be used in both PINT and SPIRITS protocols. Note, however, that in SPIRITS the PSTN notification may arrive without a particular subscription to an event (in the case of a statically set DP). 7. Follow-up on Event Notifications The requirements of this section are neither PINT-specific, nor IN- specific; their role is to outline the remaining element necessary for the delivery of the SPIRITS service, which is the reaction to the notification received. In a particular scenario where a) The IP subscriber registers a SPIRITS service; b) A call triggering the SPIRITS service is received (and notification is sent); and c) The call disposition is performed by the end user, the signalling flow is demonstrated in Figure 2. IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman July 2000 [Page 7] |----> REGISTER ----->| SPIRITS |<---- EVENT <-----|SPIRITS Proxy |----> DISPOSITION ---->| Client | | | | | V Service Control | | V SSP Figure 2: Sequence of SPIRITS actions One of the following actions is required by benchmark services: a) Accept the incoming call. b) Reject the incoming call. c) Redirect the incoming call. d) Accept the call via VoIP (this particular item is outside of the scope of SPIRITS WG). Accordingly, the SPIRITS protocol should define the following message types: a) S->P: b) S->P: <[Reject Call],[Cause]> c) S->P: <[Redirect Call],[Redirection Destination]> 8. 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. IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman July 2000 [Page 8] Parameters should be event-specific, the folowing generic types of parameters are expected to be mandatory: - timer (for no answer) - midcall control info (for mid_call) - number of digits (for collected_information) 9. Security Considerations It is assumed that the interface C is between trusting entities. Thus, there are no particular IN-related or requirements to the protocol pertinent to this interface. The assumption that the PINT Client and SPIRITS Server are co-located dictates that the security considerations for the A and B interfaces are exactly same. 10. References [1] L. Slutsman (Ed.) et al, The Spirits Architecture. , Work in Progress. July 2000. [2] H. Lu (Ed.) et al, Pre-Spirits Implementations of PSTN-initiated Services, , Work in Progress. July 2000. [3] S. Petrack, and L. Conroy, The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services, Proposed Standard. RFC 2848. 11. Author's Addresses Lev Slutsman AT&T Laboratories 200 Laurel Ave. Middletown, New Jersey, 07748 Phone: (732) 420-3752 Email: lslutsman@att.com Igor Faynberg Bell Labs/Lucent Technologies Room 4C-611A, 101 Crawfords Corner Road Holmdel, New Jersey, 07733 Phone: (732) 949-0137 Email: faynberg@lucent.com Jorge Gato Airtel Movil, S.A. Avda de Europa, 1. 28108 Alcobendas (Madrid). Spain Tel: +34 607 13 31 10 IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman July 2000 [Page 9] Fax. +34 607 13 30 57 Email: jgato@airtel.es Hui-Lan Lu Bell Labs/Lucent Technologies Room 4C-607A, 101 Crawfords Corner Road Holmdel, New Jersey, 07733 Phone: (732) 949-0321 Email: huilanlu@lucent.com 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. IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman July 2000