IPTEL Working Group Janusz Dobrowolski Warren Montgomery Kumar Vemuri Internet Draft John Voelker Alec Brusilovsky Lucent Technologies Expires: December 1999 IN Technology for Internet Telephony Enhancements 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. - 2 - 1. Abstract The purpose of this Internet Draft is to start discussion on the issues of making available existing Intelligent Network (IN) capabilities to the Voice over IP (VOIP) Internet application and other Internet applications. In addition to benefitting from accessing existing IN services, interworking with IN will expedite development of new Internet applications. The goal of this contribution is to assist: A) in development of new voice over Internet (VOIP) applications interworking with IN, B) making available to existing VOIP applications existing IN services, C) making available to non-VOIP Internet applications existing IN services, D) perhaps new non-VOIP Internet applications using existing IN services. 2. Motivation The widespread adoption of VOIP technology by end-users requires enhanced services. These services can be provided by exploiting the existing Intelligent Network infrastructure. The IN infrastucture is well established and has a proven track record of high capacity, scalability, and robustness. Although the reliability of the existing IN is based partly on the robustness of SS7; it also derives from the high reliability of the SCP equipment which could be adapted to provide services without SS7. Incidentally, the SCP may also be a suitable platform to implement reliable policy/profile servers for the Internet. In addition, the IN has wide user/business acceptance. Users of VoIP applications would benefit from consistent feature operation for both PSTN and IP end-points. Interworking VOIP with IN services in the existing wireless and wireline networks provides this consistency. The benefits of consistency accrue not only to the end-users but also to network operators. This efficiency comes from - 3 - reducing the need for separate maintenance of user and service (e.g. "follow me") data for IP and PSTN end-users. 3. IN/VOIP Interworking In order to both use existing IN services and to develop new services using existing IN capabilities, it is necessary for call control functions in the Internet to interwork with a Service Control Point (SCP). Through a transaction oriented protocol the SCP can direct the routing and call logic sequencing of the Service Switching Point (SSP). The SSP, following a finite state machine call model [3], reports particular call events to the SCP which then applies its database and service logic capabilities to tell the SSP what to do next. The network view shown in Figure 5 in [5] illustrates how IN equipment can fit into the network world. (The SSP function is performed by the call controllers in this figure. For clarity, we are referring to this function in the IP network as the soft SSP.) 3.1 Why use a Call Model? Some IN services (e.g. number portability, simple 800 calls) involve relatively simple database lookups on the SCP and a single message exchange with the SSP. For such services, it would be possible for the call controller to formulate a simple query message and process the results without implementing the complete call state model expected by the SCP. On the other hand, many services (e.g. advanced 800 service, virtual private network, follow me routing) can not be implemented using a simple database query. These service may involve several message exchanges with the SSP and require the SSP to implement the IN call model so that both SSP and SCP have a common context for interpreting those messages. By implementing the IN call model in the call controller, the call controller gains access to a - 4 - significantly richer set of services than can be obtained by simply querying routing data in the SCP. 3.2 Implementing an SSP call model To implement an SSP call model, the call controller must implement the same state machine and trigger points as defined for a PSTN SSP. The state model must be implemented in the context of the state model defined by the IP telephony protocols in use (e.g. H.323). In processing the IP telephony messages related to call control, the call controller must step through the states defined in the SSP call model and determine at each transition whether to trigger a transaction with the SCP. The processing of a single call control message or event by the call controller may cause transition through several IN call model states and potentially trigger more than one interaction with the SCP. Different state models and triggers are applied to the originating and terminating parties in a call, and the decision of when to trigger and what information to supply to the SCP may depend on the identity of the originator or terminator as well as global information about the call (e.g. a dialed number representing a feature activation code). Mapping of the IN call models and triggers to IP telephony call control architectures is an area where standards need to be developed to ensure consistent implementation. 4. Basic Call State Model The SSP Call Model is specified in terms of two finite state machines (O_BCSM and T_BCSM) and is referred to as the Basic Call State Model (BCSM). The O_BCSM models the originating side of the call and the T_BCSM models the terminating side. Call Models in wireline and wireless telephony are derived - 5 - from the generic Call Model specified by the International Telecommunication Union (ITU). Different call models exist today due to variations in network evolution around the world and due to the fact that the requirements for wireline and wireless networks were often developed separately. 5. The Soft SSP To use the IN services you have to implement the SSP function. To refer to an SSP designed for use in the Internet environment we adopt the term soft SSP. For an SCP to interwork with a soft SSP, the SCP must either support TCAP over IP or the soft SSP must support TCAP over SS7. In the latter case, either the SSP could support SS7 directly or a signaling gateway could provide this signaling interworking. A closely related issue is that a soft SSP needs to identify the particular SCP appropriate to handle a particular trigger. Also, the SCP must be able to return a response to the correct soft SSP. This translation function, known to the telephony community as Global Title Translation (GTT), is provided in the PSTN by the SS7 protocol stack. The issue of protocol interworking at the layers below TCAP and the issue of providing GTT functionality are not intended to be addressed here except to note that various solutions have been proposed. With H.323 the Gatekeeper provides a possible place to implement the soft SSP function. With SIP, a proxy server may assume this role. A media gateway controller is another possibility. - 6 - 6. Call Processing Language (CPL) and IN CPL[4] is structured as set of condition/action pairs. CPL conditions detected in the soft SSP may reflect call model detection points or triggers as well as TCAP messages incoming from the SCP. CPL action scripts may include the action of sending a particular TCAP messages to an SCP to invoke its service logic capabilities. 7. Security Issues Access to IN components must be controlled and regulated very carefully since security can be more easily breached through the IP network. Since IN components (SCPs and Intelligent Peripherals) may be shared by PSTN end-users and IP end-users, services to both groups could otherwise be compromised. A thorough analysis of these issues merits its own draft. 8. Call Model Standards The most widely deployed SSP call models today are in: 1) AIN.1 for Wireline Network 2) IS-41 for Wireless Network 3) ETSI for Wireline Network 4) GSM Wireless Network The above Call Models are documented in the following standards: The next three specifications are for landline IN. The ETSI (www.ETSI.fr) call model for the SSP is ETSI 300-374. ITU (www.itu.ch) Defines call models for both Capability Set 1 (CS1) and Capability Set 2 (CS2). - 7 - The former is used in the current installed base of IN equipment. The later is coming on stream. For CS1, the call model for the SSP is ITU-T Recommendation Q.1214. For CS2, the call model for the SSP is ITU-T Recommendation Q.1224. These models serve as reference models. The Bellcore (www.bellcore.com) model is known as AIN.1. The call model for the SSP is contained in GR1298. These next two specifications are for wireless IN. The GSM call model is contained in Q.1224 with minor augmentation by CAMEL. CAMEL (Customized Application for Mobile network Enhanced Logic) is an ETSI GSM standard. See GSM 03.78 for the call model. The ANSI (www.ansi.org) specification is known as IS41. Its SSP call model is the TIA document TN3661 (out for ballot for Wireless IN Distributed Functional Plane) 9. References [1] J. Postel, RFC 1543, "Instruction to RFC Authors". October 1993 [2] ITU-T Q.12xx Recommendation Series, Geneva, 1995. [3] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The Intelligent Network Standards, their Application to Services". McGraw-Hill, 1996. [4] J. Lennox, H. Schulzrinne, "Call Processing Language Requirements", July 30, 1998. [5] F. Cuervo, N. Greene, M. Holdrege, L. Ong, C. Huitema, "SS7-Internet Interworking - Architectural Framework", July, 1998. - 8 - 10. Authors' Address Janusz Dobrowolski E-mail: jdobrowolski@lucent.com Telephone: +1-630-979-6698 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA Warren Montgomery E-mail: wamontgomery@lucent.com Telephone: +1-630-713-5090 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA Kumar Vemuri E-mail: vvkumar@lucent.com Telephone: +1-630-224-2406 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA John Voelker E-mail: jvoelker@lucent.com Telephone: +1-630-713-5538 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA Alec Brusilovsky E-mail: abrusilovsky@lucent.com Telephone: +1-630-713-8401 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA - 9 - 11. Glossary AIN Advanced Intelligent Network IN Intelligent Network PSTN Public Switched Telephone Network SCP Service Control Point SSP Service Switching Point VoIP Voice over IP (Internet Protocol) 12. Acknowledgments The authors would like to acknowledge Jack Kozik and John Stanaway for their insightful comments presented at the working discussions that lead to the creation of this document.