H. Schulzrinne Columbia University L. Slutsman AT&T Labs Individual Contribution I. Faynberg July 2000 H. Lu Lucent Technologies Interworking between SIP and INAP 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 goal of this document is to identify a new IETF work item. The document defines the term "soft switch" as a mechanism by which PSTN Intelligent Network (IN) service control can be accessed by VoIP gateways and associated SIP servers. The document mechanism for interworking of the Session Initiation Protocol (SIP) and Intelligent Network Application Part Protocol (INAP). July 2000 Interworking between SIP and INAP [Page 2] 1. Introduction This document first defines the term "soft switch" for the purposes of describing a mechanism by which existing PSTN Intelligent Network (IN) service control can be re-used in IP networks. IP telephony is one application that can benefit from this mechanism, but there are other potential applications of interest (for example, Unified Messaging), which this draft does not address. Specifically, the document explicitly demonstrates the role of the soft switch in IP telephony. The document then narrows, for p practical purposes, the scope of the soft switch so as to identify an architecture and mechanism for interworking of Session Initiation Protocol (SIP) and Intelligent Network Application Part Protocol (INAP). The so defined mechanism can be implemented as an application layer protocol, when architectural entities reside in different machines, or inter-process communications protocol, if they reside in the same machine. It is the proposal of this document to define at least a meta-protocol (from which particular implementations can be derived) a work item in the IETF. Some (but not all) parts of this work have already been discussed in the IETF. To help delineating the proposed work item, this Internet draft explains how it relates to the efforts of the existing IETF working groups that deal with the protocols for PSTN/Internet interworking (IPTEL, MEGACO, PINT, SPIRITS, and SIGTRAN) and ITU-T. The remaining sections of this document present, in this order, the problem statement, proposed area of standardization and service examples, relation of the proposal to the existing work in the IETF and other standards bodies, security considerations, acknowledgments, conclusion, references, and an appendix with figures. 2. Problem Statement We address the porting of services that exist today in the PSTN network to IP telephony gateways, provided by the Intelligent Network (IN). Such services include "freephone" (known as "800 number" in the US), Local Number Portability (LNP), Virtual Private Network July 2000 Interworking between SIP and INAP [Page 3] (VPN) and other services. We first explain the basics of IN. Figure 1 shows a simplified IN architecture, in which telephone switches, called Service Switching Points (SSPs), are connected via a packet network called Signaling System No. 7 (SS7) to Service Control Points (SCPs), which are general purpose computers. At certain points in a call, a switch can interrupt a call and request instructions from an SCP. The points where a call can be interrupted are standardized within the Basic Call State Model (BCSM) [1]. The BCSM models contains two processes, one each for the originating and terminating part of a call. When the SCP gets an request for instructions, it can reply with a single response, such a simple number translation augmented by criteria like time of day or day of week, or, in turn, get into a complex dialog with the switch. The situation is further complicated by the necessity to engage other specialized devices, which collect digits, play recorded announcement, perform text-to-speech or speech-to-text conversion, etc. (These devices are not discussed here.) The related protocol as well as the BCSM is standardized by the ITU-T and known as the Intelligent Network Application Part Protocol (INAP). Only the protocol, but not an SCP API, have been standardized. A soft switch is a process that behaves like a PSTN switch to any PSTN entity, such as SCP or SSP, and speaks IP signaling protocols. As depicted in Figure 2, a soft switch can "talk" SS7 to SCPs and PSTN switches (thus acting as an SSP), and at the same time be a Media Gateway Controller to a Media Gateway, "speak" H.323 to a Gatekeeper and act as a SIP UA. Here, we are only concerned about the interaction of SIP and INAP, not the remaining aspects of a softswitch. In addition to the softswitch scenario, we can also have a SIP call-stateful proxy server, presumably associated with a softswitch, interact with an SCP. In that configuration, the SCP effectively acts as a SIP location server (Figure 3). July 2000 Interworking between SIP and INAP [Page 4] We do not intend to consider the issue of how the softswitch "finds" the right SCP or how it authenticates itself to the SCP. The transport of INAP messages is outside the scope of this work as well. SIN can be thought as something similar to the SIP Common Gateway Interface (CGI), specialized for INAP interworking. Unlike sip-cgi, which is transaction-oriented (although cross-transaction state can be maintained with some effort), a SIN mechanism should be call-oriented, as that corresponds more closely to the BCSM. Initial work on mapping between the SIP and IN call models has been done in the IPTEL group [3,4,5]; it may be appropriate to continue this work in an IN-focused venue such as SIN. 3. Interface between SIP servers and INAP/SCP (SIN) When interworking between VoIP and IN-PSTN networks the main issue is to translate between the states produced by VoIP signaling and those used in traditional IN environment. 3.1 The concept of state in SIP In a SIP call, only UAs have to maintain SIP call state. All other servers can be either stateless, or, in the case of proxy servers, only maintain transaction state. (Transaction state is maintained for a single SIP request only.) Proxy servers can choose to be call-stateful if necessary. In that case, they generally ensure their presence in all SIP signaling exchanges by adding their name to the SIP Record-Route list. However, the softswitch acts as a SIP UA, so this is of no concern. July 2000 Interworking between SIP and INAP [Page 5] 3.2 SIN issues When interworking between VoIP networks and IN, it is useful to have a common understanding of how to translate from the states produced by VoIP signaling to those familiar with IN service creation. In this model, each SIP server is pre-configured to communicate with one logical SCP server, using whatever communication mechanism is appropriate. (In particular, the mechanism may not use an IP network.). Different SIP servers, e.g., in different administrative domains, may communicate with different SCP servers, so that there is no single SCP server responsible for all SIP servers. July 2000 Interworking between SIP and INAP [Page 6] This proposal is applicable only when SIP-controlled Internet telephony devices are to interoperate with PSTN devices. The SIP UAs using this interface would typically appear together with a media gateway. It is *not* applicable within an all-IP network and is not needed where PSTN media gateways (not speaking SIP) need to communicate with SCPs. This proposal is not a wire protocol, but rather an abstract interface mechanism that simplifies the construction of SIP servers that want to access IN services. (On initial inspection, it does not seem appropriate to repackage SIP requests and responses.) Since SIP proxy and redirect servers do not have access to the media data path, special mechanisms need to be deployed to enable IN services such as digit collection or announcement services. Announcement services can use the mechanism in draft-ietf-sip-183 to deliver messages or can proxy the call to a SIP UAS that also terminates the data stream. That UAS may then transfer the call (draft-sparks-sip-cc-transfer) to the final destination. 4. Related IETF efforts The IETF IPTEL, MEGACO, PINT, SPIRITS, and SIGTRAN WGs deal with related interworking issues. Thus, it may turn out that this work can be accomodated within an existing working group. IPTEL: The scope of this WG are perhaps closest to the present proposal. In fact, the original proposes for call model mapping have all been presented to IPTEL. Yet IPTEL deals with two specific items, namely Call Processing Language and TRIP, which are unrelated to the problem discussed here. MEGACO: This WG develops the Media Gateway Control Protocol, which operates between the MG and the MGC and does not directly intersect with INAP and service issues. PINT and SPIRITS: These WGs address the other side (relative to the soft switch) of Figure 2, namely interworking of service control with Internet-provided services. As such, neither group has anything to do with the softswitch or VoIP-PSTN gateways and, consequently, the proposal. July 2000 Interworking between SIP and INAP [Page 7] SIGTRAN: This WG specifies a transport protocol for carrying SS7 messages, which is orthogonal to service interworking. 5. Security Considerations Since the softswitch has access to services in the PSTN network, it needs to be secured to prevent unauthorized use. However, since no protocol is being specified, this is primarily an operating system access control issue. 6. Conclusion This document has identified a new work item for the IETF to define a mechanism that simplifies the interworking of SIP-enabled softswitches with SCPs speaking INAP. 7. References [1] I, Faynberg, "Intelligent Network Standards", McGraw-Hill,1997. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:Session Initiation Protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, March 1999. July 2000 Interworking between SIP and INAP [Page 8] [3]. L. Slutsman, G. Ash, F. Haerens, Vijay K. Gurbani, "Framework and Requirements for the Internet Intelligent Networks (IIN)", Internet Draft , April 2000. Task Force, December 1999, work in progress. [4] V. Gurbani, "Accessing IN Services from SIP Networks," Internet Draft , Internet Engineering Task Force, December 1999, work in progress. [5] F. Haerens, "Intelligent Network Application Support of the SIP/SDP Architecture", Internet Draft , November 1999, work in progress. [6] J. Rosenberg, J. Lennox, and H. Schulzrinne, "Programming Internet Telephony Services," Technical Report CUCS-010-99, Columbia University, New York, New York, March 1999. [7] J. Lennox, J. Rosenberg, H. Schulzrinne, "Common Gateway Interface for SIP", Internet Draft, , June 5, 2000. 8. Acknowledgments Janusz Dobrowloski, Vijay Gurbani, Frans Haerens, Jack Kozik, Warren Montgomery, and Jonathan Rosenberg contributed to discussion on the relationship of IN and SIP call models. (Janusz was the first to bring the discussion to the IETF.) 9. Authors' Addresses Henning Schulzrinne Department of Computer Science Columbia University Phone: (212) 939-7042 Email: hgs@cs.columbia.edu Lev Slutsman AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 Phone: (732) 420-3752 Email: lslutsman@att.com Igor Faynberg Bell Labs/Lucent Technologies Room 4C-611A 101 Crawfords Corner Road Holmdel, NJ 08816 Phone: (732) 949-0137 Email: faynberg@bell-labs.com Hui-Lan Lu Bell Labs/Lucent Technologies Room 4C-607A 101 Crawfords Corner Road Holmdel, NJ 08816 Phone: (732) 949 949-0321 Email: hui-lan.lu@lucent.com July 2000 Interworking between SIP and INAP [Page 9] 10. Full Copyright Statement Copyright (C) The Internet Society (1998). 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 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. 11. Appendix Figure 1. Simplified IN Architecture +-----------+ | | | SCP | | | +-----------+ | | / \ / \ / INAP \ / \ / \ +--------+ ISUP +--------+ | SSP |*********| SSP | +--------+ +--------+ July 2000 Interworking between SIP and INAP [Page 9] Figure 2. Simplified softswitch architecture +-------------+ | | | SCP | | | +-------------+ | | INAP | +--------+ +-----------+ +---------+ | |Megaco| SIN | ISUP| SSP | | MG |------| SoftSwitch|-----| | | | | SIP | +---------+ +--------+ +-----------+ Figure 3. SIP proxy using INAP as a location server +-------------+ | | | SCP | | | +-------------+ | | INAP | +------------+ +-----------+ | | | [SIN] | | | |...........| | | SIP | SIP | SIP | softswitch |------| proxy |----- | | | server | +------------+ +-----------+ July 2000