MMUSIC WG Steve Donovan Internet Draft Matthew Cannon MCIWorldcom draft-donovan-sip-gw-client-00.txt November 15, 1998 Expires: May 15, 1999 A Functional Description of a SIP-PSTN Gateway STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 mate- rial or to cite them other than as ``work in progress''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. 1 Abstract This document describes a functional model of a gateway between the Public Switched Telephony Network (PSTN) and a SIP-based IP network providing telephony service. In this document, the SIP-based IP network will be referred to as Telephony over IP Service (TIPS). The primary function of the gateway is to handle connections involving one or more PSTN phones (i.e.; PSTN black phones) as if those PSTN phones are SIP clients. The goal of this approach is to ensure that SIP-based TIPS service logic applies to both native Internet- based SIP clients and PSTN phones without modification. 2 Introduction There is currently significant effort being put into defining how the existing PSTN networks will interwork with the Internet. The current focus of these efforts is to define how voice-based services will work between these networks. There are two primary approaches emerging in this definition. The first attempts to model the Internet-based telephony solutions on the existing PSTN architecture. With this approach, all Internet-based telephone devices would be put under the control of PSTN like control entities. While this approach will likely work, as it builds on what Page 1 Internet Draft November 17, 1998 has proven to be successful, albeit with limitations, from the PSTN networks, it unnecessarily constrains the solutions that can be implemented on the TIPS. The incredible growth of the WWW argues for an approach that is not modeled on PSTN-like hierarchical control elements but rather on a distributed model similar to generic WEB services. It is this model that was the genesis of the Session Initiation Protocol, which is built on the HTTP protocol. Using this model, all users of the TIPS are modeled as SIP clients. This includes clients that access the TIPS from PSTN phones. This requires the gateway function that implements the interworking between the PSTN and the TIPS to provide SIP client functions for all calls passing through the gateway. Based on this architectural direction, this paper proposes both a functional decomposition and network model for the reference network elements defined in draft-greene-ss7-arch-frame-01.txt. 3 Gateway Functional Elements The following is a description of the functional elements of the PSTN to SIP TIPS gateway. Signaling Gateway - This function terminates the signaling associated with a given PSTN channel/circuit. There are multiple types of SGs in this model. The following is a partial list of such Signaling Gateways: SS7 Signaling Gateway - This SG type terminates call associated SS7 signaling. One example of the SS7 signaling is ISUP. Note that in this model the SG does not handle TCAP messaging, although a TCAP SG could easily be added to the model. ISDN Signaling Gateway - This SG type terminates ISDN call associated signaling. CAS Signaling Gateway - This SG type terminates signaling associated with CAS circuits. Examples include MF and R2-based circuits. Media Gateway - This function is very similar to that proposed in the SS7 architecture framework. This function will implement the media level interworking between the PSTN circuit and an RTP flow. SIP Client - This function will handle the session initiation signaling on the IP side of the gateway. RTP Client - This function will handle the RTP flow. Page 2 Internet Draft November 17, 1998 Media Control - In this model the function of Media Control is split between the gateway and a SIP server. However, the SIP server function is not required in this model, in which case the full MC function would be imbedded in the gateway. 4 Gateway Types Although the functions of the gateway do not depend on the type of PSTN signaling used, the following functional models of the gateways are provided for illustrative purposes. Note that this description of gateway types does not assume that they would be deployed separately. It is expected that a single gateway instance would be able to handle multiple PSTN signaling types. 4.1 ISDN Gateway An ISDN Gateway will handle the interface to ISDN-based PSTN trunks and lines. +-----------------------+ | | | +------+ +--------+ | +--------+ D-Channel | | ISDN | | SIP | | SIP | SIP | <----------->| SG |<->| Client |<---------->| Server | | +------+ +--------+ | | or | | ^ | | Client | | | | +--------+ | v | | +------+ +--------+ | +--------+ B-Channel | | ISDN | | RTP | | RTP | SIP | <--------->| | MG |<->| Client |<---------->| Client | | +------+ +--------+ | | | | | +--------+ +-----------------------+ Page 3 Internet Draft November 17, 1998 4.2 CAS Gateway A Channel Assocated Signaling Gateway will handle the interface to CAS- based PSTN trunks and lines. +-----------------------+ | | | +------+ +--------+ | +--------+ | | CAS | | SIP | | SIP | SIP | | | SG |<->| Client |<---------->| Server | | +------+ +--------+ | | or | | ^ | | Client | | | | +--------+ | v | | +------+ +--------+ | +--------+ Circuit | | CAS | | RTP | | RTP | SIP | <--------->| | MG |<->| Client |<---------->| Client | | +------+ +--------+ | | | | | +--------+ +-----------------------+ 4.3 SS7 Gateway A SS7 Gateway will handle the interface to PSTN trunks that are controlled by ISUP, TUP or other SS7-based call signaling methods. This type of gateway is differentiated from the ISDN and CAS gateways by the fact that it must be implemented in a fashion that allows the SG function can be deployed separately from the MG function. This is due to the relative expense of the SS7 link and the scarcity of SS7 point codes. +-----------------------+ | | | +------+ +--------+ | +--------+ SS7 Link | | SS7 | | SIP | | SIP | SIP | <----------->| SG |<->| Client |<---------->| Server | | +------+ +--------+ | | or | | ^ | | Client | | | | +--------+ +-----------------------+ | | +-----------------------+ | | | | v | | +------+ +--------+ | +--------+ Circuit | | SS7 | | RTP | | RTP | SIP | <--------->| | MG |<->| Client |<---------->| Client | | +------+ +--------+ | | | | | +--------+ +-----------------------+ Page 4 Internet Draft November 17, 1998 5 Interfaces The definition of the internal interfaces is outside of the scope of this document and is assumed to be an implementation issue. It is important that all other interfaces be standardized. The SIP and RTP standards are already in various stages of standardization. The interface between the SS7 SG and the SS7 MG will require standardization. The current work on the MGCP protocol is one candidate for this interface. Another option is extensions to the SIP protocol. 6 DTMF Handling An important function of the gateway is to convey all signaling information received from the PSTN to the TIPS. In all three gateway types defined, signaling information can occur as DTMF digits encoded into the voice stream. This "inband" call control information can be used for communications between the PSTN user and another end device, for example a service node or the user's at-home answering machine. In this case, it is envisioned that the DTMF information will be carried in the TIPS as part of the RTP stream. This call control information can also be used for interactions with service control logic generally deployed in the PSTN in Service Control Points. It is envisioned that the same method of communication between PSTN-based clients of the TIPS and the TIPS-based service control will be required. As such, it is important that the gateway be able to detect and report on the presence of DTMF digits in the voice stream. Note that it is expected that a similar method of communicating between native SIP clients and TIPS service logic will be required for SIP clients with nothing more than a telephone keypad available to control service logic. There is work currently underway to define extensions to the SIP protocol that will allow for an interested IP host, for instance a SIP server, to request notification of call events. One such use of this extension will be to request notification of the detection of DTMF digits. This would allow the SIP server, or other interested host, to use the DTMF digits for service control logic. 7 Conclusion It is important that the definition of the interface between the PSTN and the Internet for telephony-based services take advantage of the richness of services made possible by the Internet and the World Wide Web. In order to ensure that this is possible, it is necessary to model the telephony services on the Internet first and then determine how to interwork with the PSTN. Page 5 Internet Draft November 17, 1998 This paper proposes doing this by treating all PSTN devices as SIP clients. In doing so, services developed for native Internet SIP clients can be offered to PSTN clients without modification. In addition, new services can be added to the TIPS with the relative ease of adding a WEB page. 8 Bibliography [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", Internet Draft, Internet Engineering Task Force, October 14, 1998. Work in progress. [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [3] F. Cuervo, N. Greene, M. Holdrege, L. Ong, C. Huitema, "SS7- Internet Interworking - Architectural Framework", Internet Draft, Internet Engineering Task Force, July, 1998. 9 Author's Address Steve Donovan MCI Worldcom 1493/678 901 International Parkway Richardson, Texas 75081 Email: steven.r.donovan@mci.com Matthew Cannon MCI Worldcom 9514/107 2400 North Glenville Drive Richardson, Texas 75082 Email: matt.cannon@mci.com Page 6