idnits 2.17.1 draft-ietf-spirits-architecture-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 7) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 370 has weird spacing: '...for the purp...' == Line 371 has weird spacing: '...ase the proc...' == Line 372 has weird spacing: '...andards proc...' == Line 373 has weird spacing: '...it into lang...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2995 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Slutsman (Ed.) 2 Internet Draft AT&T Labs 3 I. Faynberg 4 Expires October 2001 H. Lu 5 M. Weissman 6 Lucent Technologies 8 The SPIRITS Architecture 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance wit all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes the architecture for supporting SPIRITS 32 services, which are those originating in the PSTN and necessitating the 33 interactions between the PSTN and the Internet. (Internet Call Waiting, 34 Internet Caller-ID Delivery, and Internet Call Forwarding are examples 35 of SPIRIT services.) Specifically, it defines the components 36 constituting the architecture and the interfaces between the components. 38 1. Introduction 40 This document describes the architecture for supporting SPIRITS 41 services, which are those originating in the PSTN and necessitating the 42 interactions between the PSTN and the Internet. (Internet Call Waiting, 43 Internet Caller-ID Delivery, and Internet Call Forwarding are examples 44 of SPIRIT services.) Specifically, it defines the components 45 constituting the architecture and the interfaces between the 46 components. 48 The rest of the document is organized as follows: 49 + Section 2 describes example SPIRITS services from the end-user point 50 of view; 51 + Section 3 describes the SPIRITS architecture; 53 November 2001 55 + Section 4 contains security consideration; 56 + Section 5 contains acknowledgments; 57 + Section 6 contains references; and 58 + Appendix contains the figure. 60 2. Brief Description of Example SPIRITS Services 62 To illustrate the motivation for the overall SPIRIT architecture, 63 this section provides a brief description of the example SPIRITS 64 services: 65 + Internet Call Waiting (ICW), 66 + Internet Caller-ID Delivery, and 67 + Internet Call Forwarding. 69 These services are considered from the end-user point of view under 70 the assumptions below: 72 + Service subscription (or cancellation) is a separate process and 73 may be done over the telephone, via postal mail, or over the Web. 75 + The subscriber's IP host (e.g., a PC) is loaded with the necessary 76 software [including a Personal Identification Number (PIN) and the IP 77 addresses of the SPIRITS servers] for realizing the SPIRITS services. 78 The software may be sent by postal mail or downloaded from the Web. 80 + The subscriber activates a SPIRITS service by an act of service 81 session registration, which can take place anytime after he (or she) 82 is connected to the Internet. The subscriber may specify the life 83 span of the session. As soon as the session ends, the SPIRITS service 84 is deactivated. Naturally, the subscriber should also be able to 85 deactivate a SPIRITS service anytime during the service session. 87 For certain services (such as ICW or Caller-ID Delivery) the 88 assumption is that the service subscriber has a single telephone line 89 and a PC, which is connected to the Internet via this telephone. 90 (Only under this assumption these services make sense.) Nevertheless, 91 in other services (such as Web-based Call Center, in which a call 92 center assistant could re-direct or reject a call presented in a 93 pop-up window) this assumption may be unnecessary or even 94 inapplicable. 96 2.1 Internet Call Waiting (ICW) 98 The Internet call waiting service enables a subscriber engaged in an 99 Internet dial-up session to 101 o be notified of an incoming call to the very same telephone line 102 that is being used for the Internet connection; 104 o specify the desirable treatment of the call; and 106 o have the call handled as specified. 108 November 2001 110 The details of the ICW service lie in the ways that a waiting call 111 can be treated [1]. Typical ways for handling a call include: 113 + Accept the incoming call over the PSTN by terminating the Internet 114 connection. (As switching cannot be done immediately, the caller may 115 hear an opening announcement followed by the "ringing" tone.) 117 + Forward the incoming call to another telephone number. The 118 subscriber will remain connected to the Internet, while the caller 119 will hear an announcement indicating the call is being forwarded and 120 eventually be connected to the new destination number. 122 + Accept the incoming call by voice over IP. The subscriber will 123 answer the incoming call via the already established Internet 124 connection. (The proposed SPIRITS architecture, however, does not 125 reflect this feature.) 127 + Redirect the incoming call to voice mail. The subscriber will 128 remain connected to the Internet, while the caller will hear an 129 announcement inviting him (or her) to leave a message. 131 + Play a pre-recorded message to the calling party and disconnect the 132 call. The subscriber will remain connected to the Internet. 134 + Reject the incoming call. The subscriber will remain connected to 135 the Internet, while the caller will hear an announcement rejecting 136 the call. 138 The subscriber may specify the call treatment on the fly when 139 notified of an incoming call. Alternatively, the subscriber may 140 specify a priori a general treatment for all calls (e.g., re-directed 141 to voice mail) or call treatments tailored to the origination 142 numbers. As a result, when a call comes in, the subscriber won't be 143 presented the call but can examine afterwards the treatment and 144 outcome of the call from the log that is kept for all the calls 145 processed during the ICW service. Typical information recorded in the 146 log includes the incoming call date and time, calling party number, 147 calling party name, and call disposition. 149 2.2 Internet Caller-ID Delivery 151 This service allows the subscriber to see the caller's number or name 152 or both while being connected to the Internet. If the subscriber has 153 only one telephone line and is using the very line for the Internet 154 connection, the service is a subset of the ICW service and follows 155 the relevant description in Section 2.1. Otherwise, the subscriber's 156 IP host serves as an auxiliary device of the telephone to which the 157 call is first sent. 159 2.3 Internet Call Forwarding 161 The Internet call forwarding service allows a service subscriber to 162 forward an incoming call to another telephone number while being 163 connected to the Internet. If the subscriber has only one telephone 165 November 2001 167 line and is using the very line for the Internet connection, the 168 service is a subset of the ICW service and follows the relevant 169 description in Section 2.1. Otherwise, the subscriber's IP host 170 serves as an auxiliary device of the telephone to which the call is 171 first sent. 173 3. SPIRITS Architecture 175 Figure 1 of the Appendix depicts the SPIRITS architecture, which 176 includes the following entities: 178 1. Service Control Function (SCF) [2], which executes service logic, 179 interacts with the entities in the IP domain (e.g., the SPIRITS 180 Gateway and PINT Server) through the SPIRITS Client, and instructs 181 the switches on how to complete a call. Physically, the SCF may be 182 located in either stand-alone general-purpose computers called 183 Service Control Points (SCPs) or specialized pieces of equipment 184 called Service Nodes (SNs) [2]. 186 2. Service Switching Function (SSF) [2], which normally resides in a 187 switch and is responsible for the recognition of Intelligent Network 188 (IN) triggers and interactions with the SCF. 190 3. SPIRITS Client, which is responsible for receiving PSTN requests 191 from the SCF as well as sending responses back. It may be co-located 192 with the SCF. If not, it communicates with the SCF over the D 193 interface. 195 4. PINT Server, which receives PINT requests from the PINT Client and 196 relays them to the PSTN for execution over the E interface. 198 5. SPIRITS Gateway, which is co-located with the PINT Server or 199 PINT Gateway (or both when they are co-located as assumed here 200 for simplicity) and serves as an intermediary between the SPIRITS 201 Server and SPRITS Client via the B and C interfaces, respectively. 203 6. PINT Client, which resides in the subscriber's IP host and is 204 responsible for initiating PINT requests, which are sent to the PINT 205 server over the A interface. 207 7. SPIRITS Server, which terminates PSTN requests and is responsible 208 for all interactions (e.g., incoming call notification and relaying 209 the call treatment) between the subscriber and the SPIRITS Gateway. 211 The rest of the Section describes the interfaces between the entities 212 in detail. 214 3.1 Interface A 216 This interface is used for sending PINT requests to PINT Server. Its 217 principal use is for service session registration and as a result 218 activation of a SPIRITS service (see Section 2). In addition, this 219 interface may be used for service subscription. 221 November 2001 223 3.2 Interface B 225 This interface serves two main purposes: 1) to notify the subscriber 226 of incoming calls together with the calling number and name, if 227 available; and 2) to send to the SPRITS Gateway the subscriber's 228 choice of call disposition specified on the fly. 230 3.3 Interface C 232 This interface is used for communications between the SPIRITS Client 233 and SPIRITS Gateway. The SPIRITS Gateway may in turn communicate 234 with the SPIRITS Server, or may act as a virtual server, terminating 235 the requests without sending them down to the SPIRITS Server. 237 3.4 Interface D 239 This interface is for communications between the SPIRITS Client and 240 the SCF. Specifically, from the SCF to the SPIRITS Client, the 241 parameters associated with the applicable IN triggers are sent. From 242 the SPIRITS Client to SCF, the subscriber's call disposition is sent. 243 The SCF "transforms" the user's disposition into appropriate actions, 244 such as playing an announcement to the caller, and resuming the 245 suspended call processing in the SSP. 247 3.5 Interface E 249 This interface is for sending PINT requests to the SCF for execution. 251 4. Security Considerations 253 It is assumed that the interface C is between trusting entities. In 254 addition, the assumption that the PINT Client and SPIRITS Server are 255 collocated dictates that the security considerations for the A and B 256 interfaces are exactly the same. 258 5. Acknowledgments 260 We would like to thank Alec Brusilovsky, Jorgen Bjorkner, Jim Buller, 261 Lawrence Conroy, Jorge Gato, Dave Hewins, Naoto Makinae, and Dave 262 Shrader for their comments and input. 264 6. References 266 [1] Lu, H. (Editor), I. Faynberg, J. Voelker, M. Weissman, W. Zhang, 267 S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, 268 J. Yoakum, and L. Robart, "Pre-SPIRITS Implementations of PSTN- 269 Initiated Services ", RFC 2995. 271 [2] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent 272 Network Standards: Their Application to Services", McGraw-Hill, 1997. 274 November 2001 276 Appendix 278 ...................... 279 +----------------+ . . 280 | +------------+ | . +------------+ . 281 | | | | A . | | . 282 | | PINT Client|********************|PINT Server/|******** 283 | | | | . Gateway | * 284 | +------------+ | . +------------+ . * 285 | | . . * 286 | Subscriber's | . . * 287 | | . . * 288 | IP Host | . . * 289 | | . +------------+ . * 290 | +------------+ | . | SPIRITS | . * 291 | | SPIRITS | | B . | Gateway | . * 292 | | Server |********************| | . * E 293 | | | | . +------------+ . * 294 | +------------+ | . * . * 295 +----------------+ . * . * 296 ...........*.......... * 297 //-------\\ * * 298 /// \\\ * * 299 | Subscriber's | * C * 300 | Telephone | * * 301 \\\ /// * * 302 \\ -------// * * 303 * * * 304 * * * 305 ++++++++++++++++++++++++++ PSTN ++++++++++++++++++++++++++ 306 * * * 307 * * * 308 * +------------------+ * 309 * Line | SPIRITS Client | * 310 * | | * 311 +--------------------+ +---+----- D ---------+-*+ 312 | | INAP/SS7 | | 313 |Service Switching ************Service Control Function | 314 | Function | | | 315 | | +-------------------------+ 316 | | 317 | | 318 +--------------------+ 320 Figure 1: SPIRITS Architecture 322 Author's Addresses 324 Igor Faynberg 325 Lucent Technologies 326 Room 4D-601A 327 101 Crawfords Corner Road 328 Holmdel, NJ 07733-3030 US 329 E-mail: faynberg@lucent.com 331 November 2001 333 Telephone: +1 732 949 0137 335 Hui-Lan Lu 336 Lucent Technologies Room 4C-607A 337 101 Crawfords Corner Road 338 Holmdel, NJ 07733-3030 US 339 E-mail: huilanlu@lucent.com 340 Telephone: +1 732 949 0321 342 Mark Weissman 343 Lucent Technologies 344 Room NE406B 345 200 Lucent Lane 346 Cary, NC 27511 347 E-mail: maw1@lucent.com 348 Telephone: +1 919 463 3258 350 Lev Slutsman 351 AT&T Labs 352 Room D5-3D26 353 200 Laurel Avenue 354 Middletown, NJ 07748 355 E-mail: slutsman@att.com 356 Telephone: 732-420-3756 358 Full Copyright Statement 360 Copyright (C) The Internet Society (1998). All Rights Reserved. 362 This document and translations of it may be copied and furnished to 363 others, and derivative works that comment on or otherwise explain it 364 or assist in its implementation may be prepared, copied, published 365 and distributed, in whole or in part, without restriction of any 366 kind, provided that the above copyright notice and this paragraph 367 are included on all such copies and derivative works. However, this 368 document itself may not be modified in any way, such as by removing 369 the copyright notice or references to the Internet Society or other 370 Internet organizations, except as needed for the purpose of 371 developing Internet standards in which case the procedures for 372 copyrights defined in the Internet Standards process must be 373 followed, or as required to translate it into languages other than 374 English. The limited permissions granted above are perpetual and 375 will not be revoked by the Internet Society or its successors or 376 assigns. This document and the information contained herein is 377 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 378 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 379 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 380 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 381 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 383 November 2001