idnits 2.17.1 draft-donovan-sip-gw-client-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 15, 1998) is 9295 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 256 looks like a reference -- Missing reference section? '2' on line 260 looks like a reference -- Missing reference section? '3' on line 264 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC WG Steve Donovan 2 Internet Draft Matthew Cannon 3 MCIWorldcom 4 draft-donovan-sip-gw-client-00.txt 5 November 15, 1998 6 Expires: May 15, 1999 8 A Functional Description of a SIP-PSTN Gateway 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 1 Abstract 32 This document describes a functional model of a gateway between the 33 Public Switched Telephony Network (PSTN) and a SIP-based IP network 34 providing telephony service. In this document, the SIP-based IP 35 network will be referred to as Telephony over IP Service (TIPS). 37 The primary function of the gateway is to handle connections involving 38 one or more PSTN phones (i.e.; PSTN black phones) as if those 39 PSTN phones are SIP clients. The goal of this approach is to ensure 40 that SIP-based TIPS service logic applies to both native Internet- 41 based SIP clients and PSTN phones without modification. 43 2 Introduction 45 There is currently significant effort being put into defining how the 46 existing PSTN networks will interwork with the Internet. The current 47 focus of these efforts is to define how voice-based services will 48 work between these networks. 50 There are two primary approaches emerging in this definition. The 51 first attempts to model the Internet-based telephony solutions on the 52 existing PSTN architecture. With this approach, all Internet-based 53 telephone devices would be put under the control of PSTN like control 54 entities. While this approach will likely work, as it builds on what 55 has proven to be successful, albeit with limitations, from the PSTN 56 networks, it unnecessarily constrains the solutions that can be 57 implemented on the TIPS. 59 The incredible growth of the WWW argues for an approach that is not 60 modeled on PSTN-like hierarchical control elements but rather on a 61 distributed model similar to generic WEB services. 63 It is this model that was the genesis of the Session Initiation 64 Protocol, which is built on the HTTP protocol. 66 Using this model, all users of the TIPS are modeled as SIP clients. 67 This includes clients that access the TIPS from PSTN phones. This 68 requires the gateway function that implements the interworking 69 between the PSTN and the TIPS to provide SIP client functions for all 70 calls passing through the gateway. 72 Based on this architectural direction, this paper proposes both a 73 functional decomposition and network model for the reference network 74 elements defined in draft-greene-ss7-arch-frame-01.txt. 76 3 Gateway Functional Elements 78 The following is a description of the functional elements of the PSTN 79 to SIP TIPS gateway. 81 Signaling Gateway - This function terminates the signaling associated 82 with a given PSTN channel/circuit. There are multiple types of SGs in 83 this model. The following is a partial list of such Signaling 84 Gateways: 86 SS7 Signaling Gateway - This SG type terminates call associated SS7 87 signaling. One example of the SS7 signaling is ISUP. Note that in 88 this model the SG does not handle TCAP messaging, although a TCAP SG 89 could easily be added to the model. 91 ISDN Signaling Gateway - This SG type terminates ISDN call associated 92 signaling. 94 CAS Signaling Gateway - This SG type terminates signaling associated 95 with CAS circuits. Examples include MF and R2-based circuits. 97 Media Gateway - This function is very similar to that proposed in the 98 SS7 architecture framework. This function will implement the media 99 level interworking between the PSTN circuit and an RTP flow. 101 SIP Client - This function will handle the session initiation 102 signaling on the IP side of the gateway. 104 RTP Client - This function will handle the RTP flow. 106 Media Control - In this model the function of Media Control is split 107 between the gateway and a SIP server. However, the SIP server 108 function is not required in this model, in which case the full MC 109 function would be imbedded in the gateway. 111 4 Gateway Types 113 Although the functions of the gateway do not depend on the type of PSTN 114 signaling used, the following functional models of the gateways are 115 provided for illustrative purposes. 117 Note that this description of gateway types does not assume that they 118 would be deployed separately. It is expected that a single gateway 119 instance would be able to handle multiple PSTN signaling types. 121 4.1 ISDN Gateway 123 An ISDN Gateway will handle the interface to ISDN-based PSTN trunks and 124 lines. 126 +-----------------------+ 127 | | 128 | +------+ +--------+ | +--------+ 129 D-Channel | | ISDN | | SIP | | SIP | SIP | 130 <----------->| SG |<->| Client |<---------->| Server | 131 | +------+ +--------+ | | or | 132 | ^ | | Client | 133 | | | +--------+ 134 | v | 135 | +------+ +--------+ | +--------+ 136 B-Channel | | ISDN | | RTP | | RTP | SIP | 137 <--------->| | MG |<->| Client |<---------->| Client | 138 | +------+ +--------+ | | | 139 | | +--------+ 140 +-----------------------+ 142 4.2 CAS Gateway 144 A Channel Assocated Signaling Gateway will handle the interface to CAS- 145 based PSTN trunks and lines. 147 +-----------------------+ 148 | | 149 | +------+ +--------+ | +--------+ 150 | | CAS | | SIP | | SIP | SIP | 151 | | SG |<->| Client |<---------->| Server | 152 | +------+ +--------+ | | or | 153 | ^ | | Client | 154 | | | +--------+ 155 | v | 156 | +------+ +--------+ | +--------+ 157 Circuit | | CAS | | RTP | | RTP | SIP | 158 <--------->| | MG |<->| Client |<---------->| Client | 159 | +------+ +--------+ | | | 160 | | +--------+ 161 +-----------------------+ 163 4.3 SS7 Gateway 165 A SS7 Gateway will handle the interface to PSTN trunks that are 166 controlled by ISUP, TUP or other SS7-based call signaling methods. 168 This type of gateway is differentiated from the ISDN and CAS gateways 169 by the fact that it must be implemented in a fashion that allows the 170 SG function can be deployed separately from the MG function. This is 171 due to the relative expense of the SS7 link and the scarcity of SS7 172 point codes. 174 +-----------------------+ 175 | | 176 | +------+ +--------+ | +--------+ 177 SS7 Link | | SS7 | | SIP | | SIP | SIP | 178 <----------->| SG |<->| Client |<---------->| Server | 179 | +------+ +--------+ | | or | 180 | ^ | | Client | 181 | | | +--------+ 182 +-----------------------+ 183 | 184 | 185 +-----------------------+ 186 | | | 187 | v | 188 | +------+ +--------+ | +--------+ 189 Circuit | | SS7 | | RTP | | RTP | SIP | 190 <--------->| | MG |<->| Client |<---------->| Client | 191 | +------+ +--------+ | | | 192 | | +--------+ 193 +-----------------------+ 195 5 Interfaces 197 The definition of the internal interfaces is outside of the scope of 198 this document and is assumed to be an implementation issue. 200 It is important that all other interfaces be standardized. The SIP and 201 RTP standards are already in various stages of standardization. 203 The interface between the SS7 SG and the SS7 MG will require 204 standardization. The current work on the MGCP protocol is one 205 candidate for this interface. Another option is extensions to the SIP 206 protocol. 208 6 DTMF Handling 210 An important function of the gateway is to convey all signaling 211 information received from the PSTN to the TIPS. In all three gateway 212 types defined, signaling information can occur as DTMF digits encoded 213 into the voice stream. 215 This "inband" call control information can be used for communications 216 between the PSTN user and another end device, for example a service 217 node or the user's at-home answering machine. In this case, it is 218 envisioned that the DTMF information will be carried in the TIPS as 219 part of the RTP stream. 221 This call control information can also be used for interactions with 222 service control logic generally deployed in the PSTN in Service Control 223 Points. It is envisioned that the same method of communication between 224 PSTN-based clients of the TIPS and the TIPS-based service control will 225 be required. As such, it is important that the gateway be able to 226 detect and report on the presence of DTMF digits in the voice stream. 227 Note that it is expected that a similar method of communicating between 228 native SIP clients and TIPS service logic will be required for SIP 229 clients with nothing more than a telephone keypad available to control 230 service logic. 232 There is work currently underway to define extensions to the SIP 233 protocol that will allow for an interested IP host, for instance a SIP 234 server, to request notification of call events. One such use of this 235 extension will be to request notification of the detection of DTMF 236 digits. This would allow the SIP server, or other interested host, 237 to use the DTMF digits for service control logic. 239 7 Conclusion 241 It is important that the definition of the interface between the PSTN 242 and the Internet for telephony-based services take advantage of the 243 richness of services made possible by the Internet and the World Wide 244 Web. In order to ensure that this is possible, it is necessary to 245 model the telephony services on the Internet first and then determine 246 how to interwork with the PSTN. 248 This paper proposes doing this by treating all PSTN devices as SIP 249 clients. In doing so, services developed for native Internet SIP 250 clients can be offered to PSTN clients without modification. In 251 addition, new services can be added to the TIPS with the relative ease 252 of adding a WEB page. 254 8 Bibliography 256 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 257 "SIP: Session Initiation Protocol", Internet Draft, Internet 258 Engineering Task Force, October 14, 1998. Work in progress. 260 [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A 261 Transport Protocol for Real-Time Applications", RFC 1889, January 262 1996. 264 [3] F. Cuervo, N. Greene, M. Holdrege, L. Ong, C. Huitema, "SS7- 265 Internet Interworking - Architectural Framework", Internet 266 Draft, Internet Engineering Task Force, July, 1998. 268 9 Author's Address 270 Steve Donovan 271 MCI Worldcom 272 1493/678 273 901 International Parkway 274 Richardson, Texas 75081 275 Email: steven.r.donovan@mci.com 277 Matthew Cannon 278 MCI Worldcom 279 9514/107 280 2400 North Glenville Drive 281 Richardson, Texas 75082 282 Email: matt.cannon@mci.com