idnits 2.17.1 draft-brusilovsky-icw-00.txt: -(107): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(110): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-19) 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. == There are 3 instances of lines with non-ascii characters in the document. == 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 12 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 211 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 12 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 17 has weird spacing: '... This docum...' == Line 18 has weird spacing: '...), its areas...' == Line 19 has weird spacing: '...and its worki...' == Line 23 has weird spacing: '...ents at any...' == Line 24 has weird spacing: '...e. It is i...' == (206 more instances...) -- 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) -- Looks like a reference, but probably isn't: 'SCF' on line 517 == Unused Reference: '5' is defined on line 392, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 395, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 398, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1543 (ref. '1') (Obsoleted by RFC 2223) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 12 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PINT Working Group A. Brusilovsky 3 Internet Draft E. Gausmann 4 V. Gurbani 5 A. Jain 6 Lucent Technologies 8 Expires: July 1999 10 A Proposal for Internet Call Waiting Service using SIP 11 An Implementation Report 13 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 This memo provides information for the Internet community. This memo 34 does not specify an Internet standard of any kind. Distribution of 35 this memo is unlimited. 37 Abstract 39 The purpose of this Internet Draft is to start discussion on the 40 issues involved in Internet Call Waiting Service (ICW), as part of 41 interconnecting IP and Global Switched Telephone Network (GSTN) with 42 the intent of providing ICW service that is much needed by numerous 43 dial-up Internet users. Interworking of the IP network and GSTN, 44 based on open well-defined protocols, will promote interoperability 45 of both the networks and systems built by different vendors. This 46 Internet Draft is submitted with the goal of becoming an 47 informational RFC. 49 The rest of this document is as follows: 51 January 1999 53 Section 2 briefly describes the services offered to the end 54 Subscriber. It is the support of these services that necessitates the 55 proposed internetworking project. 57 Section 3 describes the scope of the proposed project by introducing 58 its overall architecture, identifying the interfaces to be 59 standardized, describing experience with SIP for ICW. 61 Sections 4, 5, and 6 respectively address security considerations, 62 supply references, and provide the authors address, as required by 63 [1]. 65 Section 7 acknowledges individuals providing assistance in the 66 creation of this document. 68 Section 8 is the Appendix, which contains IN Tutorial and Figure A. 70 2. Service Description 71 It is a well-known problem that call waiting tone interferes with the 72 operation of a modem. Anyone using the telephone for a modem 73 connection to a host computer can not gracefully deal with incoming 74 call waiting calls. Internet Call Waiting is the capability to 75 provide incoming call notification and completion options when the 76 Subscriber is on a dial-up IP connection. When a call comes in the 77 Subscriber is presented with a pop-up dialog box, that presents the 78 caller's number and, optionally, his or her name. Internet Call 79 Waiting solution provides a simple, graphical-oriented way to notify 80 subscribers while connected to the Internet, of incoming calls. It 81 allows the subscriber to accept or reject the call. 83 Benefits 85 Service providers can achieve the following important benefits 86 through the use of Internet Call Waiting Service: 88 o More calls completed. Call completion is an important aspect of 89 the service provided by telecommunication operators. Calls that end 90 in busy or no- answer, consume network resources. Solution like 91 Internet Call Waiting contributes to greater call completion which 92 lowers expense and provides value to both the consumer and service 93 provider. 95 o The ICW platform is the foundation to offer services: The service 96 provider has the opportunity to enhance Internet Call Waiting with 97 other services like Internet Follow-me, personalized call management, 98 unified messaging service, click to return (dial) an important call, 99 and other call management functions which integrate voice and data 100 services. 102 o Service provider can offer the following important benefits to the 103 subscribers through the use Internet Call Waiting Service: 105 January 1999 107 � Simple way to manage voice and data calls over a single telephone 108 line. 109 � Ability to track all incoming calls while the service is active 110 � PC Graphical Subscriber Interface provides a simple intuitive 111 Subscriber interface and also allows easy customization. 113 3. Scope of the Proposed Project 115 Figure A illustrates the hardware architecture that will support ICW 116 Service. The lines indicate the control and/or voice paths. Control 117 paths are labeled by the protocol that will be used over them. 118 IN elements (SCP, SMS, SSP) are specialized servers, connected to 119 switches and other network elements. They handle data queries and 120 updates, specialized call routing and other advanced telecom 121 services. For more information on Intelligent Network please see our 122 IN Tutorial in the Appendix of this Internet Draft. 124 The following software components make up the ICW architecture. 126 o ICW User Agent Server (UAS) - The ICW UAS (SIP Client) and server 127 communicate via the SIP protocol over TCP/IP. The ICW UAS can start 128 up automatically as soon as a PPP connection is established. It also 129 responds to the incoming request for call treatment by popping up the 130 dialog box to the subscriber presenting information about the 131 Calling Party and asking for an Accept or Reject decision. The UAS 132 sends the resulting choice back to the ICW server. In the case of a 133 accepted call, the UAS drops the modem connection to the ISP to allow 134 the incoming call to complete. 136 o ICW server - a SIP proxy server that perform the following 137 functions. The SCP is not being used as a general-purpose database 138 host. Thus, SIP-related database dips are envisioned to be in the 139 domain of a generic ICW server which can interface with any 140 commercial-grade database engine or any LDAP-enabled database. The 141 SCP is free to provide telecommunication intensive tasks that it was 142 designed for. 144 - Listening for incoming messages from the application running on 145 SCP 146 - Providing a data store mechanism for ICW applications 147 - Handling Web-based GUI (Applet) requests for subscriber 148 provisioning on the ICW server 150 o SCP platform software - The ICW APPLICATION runs on SCP 152 - ICW Application runs on SCP - The AIN 0.1 Terminating Attempt 153 Trigger (TAT) is used to enable PSTN call handling. Thus, the 154 Application responds to an AIN message for every call to the 155 subscriber. For each call, the Application either returns a 156 request for normal routing, if the subscriber is no longer active, 158 January 1999 160 or sends a message to the ICW server passing along the calling 161 number. Based upon the reply from the ICW server, which may be 162 Accepted or Rejected, the SCP sends the appropriate instructions ba 163 ck to the SSP. 165 Various alternatives exist for firewall support. The ICW 166 UAS-to-ICW server firewall could be standard corporate security 167 firewall. However, the security policy would need to allow 168 TCP-based SIP messages to flow between the ICW UAS and server over 169 the standard SIP port 5060. The ICW server-to-SCP firewall is 170 optional and could be used to provide an extra level of protection 171 for the SCP by restricting Intranet access or by enforcing a more 172 restrictive security policy than the outer firewall. General and 173 ICW specific security considerations are covered in Section 4. 175 Other components in the diagram are part of the standard Internet 176 and PSTN and include the Internet Service Provider (ISP), ISP 177 modems and web servers, the Service Switching Point (SSP) and the 178 Signal Transfer Point (STP). The SSPs must be provisioned with the 179 necessary trigger for the ICW service, the AIN 0.1 Terminating 180 Attempt Trigger. 182 When the Calling Party dials the ICW Subscriber's Destination Number, 183 the Calling Party experiences the standard Call Waiting treatment, 184 ringing, until Calling Party abandons or the Subscriber specifies 185 treatment: Subscriber treatment options and Calling Party experience 186 are: 187 o Refuse Call: Calling Party hears ringing until Calling Party 188 abandons. In SIP terms, this results in the SIP UAS sending a "603 189 Decline" message to the ICW server. 190 o Hold Call: Calling Party hears [optional] announcement to hold 191 while "other" call in progress is completed. The intent is that the 192 Subscriber will accept the call momentarily. (Another possibility 193 would be to tell the Calling Party that you'll call them back in a 194 few minutes, etc) In SIP terms, this results in the SIP UAS sending a 195 "182 Queued" message to the ICW server. 196 o Send to Voice Mail (assuming Subscriber has a Voice Mail service): 197 Calling Party hears voice mail system announcements. (This 198 redirection to voice mail could, as well, have been redirection to 199 some other DN, e.g. cell phone, second line, secretary, etc) In SIP 200 terms, this results in the SIP UAS sending a "380 Alternative 201 Service" to the ICW server. 202 o Accept Call: Calling Party hears ringing until is connected to 203 Subscriber. In SIP terms, this results in the SIP UAS sending a "200 204 OK" to the ICW server. 205 Note: Optional treatment options can include taking call via VoIP and 206 route call to a third party number. 208 In the proposed Architecture, the Subscriber is assumed to have PPP 209 service through their ISP. They are surfing the Internet or working 210 at home, connected to a corporate intranet. Two components of ICW 212 January 1999 214 reside on their PC; an H.323 client for VoIP and an ICW UAS to drive 215 the presentation to the Subscriber of Setup and Notification. 216 Controlling the ICW service is the ICW server for Internet related 217 control and the combination of the SCP and SSP via AIN functionality 218 providing PSTN control via SS7. There is an ICW control session 219 between the PC and the ICW server. Controlling the VoIP aspect is 220 the H.323 client at the PC and the H.323 gateway with H.323 packets 221 going between them via the internet. The SCP controls the IP via 222 Bellcore's GR-1129. The SCP and ICW server have a TCP/IP connection. 223 The call path of the accepted call consists of the Calling Party 224 being routed to the IP (intelligent peripheral) and bridged to the 225 ICW Subscriber from the H.323 gateway. Firewall appliances are 226 placed on all IP connections of the service provider. A call 227 scenario below walks through this architecture. Integration of the 228 H.323 GW and IP as well as the SCP and ICW server is a possibility 229 for future enhancements. 231 Call Scenario 233 Subscription to the service. 234 o Subscriber signs up for the service. 235 o Subscriber downloads and installs the ICW UAS software. 236 o Subscriber Information is provisioned in the SMS (and SCP). 238 Activation of the service and coordination with the ICW Server 239 (Transparent for the ICW User) 240 o ICW UAS establishes TCP connection. 241 o Subscriber authenticates himself/herself and Register with ICW 242 Server using the encrypted password and phone number. 243 o ICW Server stores information in database. 245 Call Arrival 246 o Calling Party initiates call to Subscriber. 247 o SSP (Switch) encounters TAT. 248 o SCP query launched. 249 o SCP determines if call is for an ICW subscriber (if not then other 250 service logic applies). 251 o SCP sends a SIP "INVITE" message with Calling Number, optional 252 Calling Name and Called Number (and receives a SIP acknowledgement 253 from the ICW Server) 254 o If ICW is activated for the called subscriber, ICW Server returns 255 "TRYING" to SCP. The SCP instructs SSP to play an announcment, e.g. 256 ringing. ICW Server determines, based on the Called Number and the 257 IP Address of the ICW UAS and sends the SIP INVITE message to the ICW 258 UAS. 259 o If ICW is not activated ICW Server returns "NOT FOUND" to SCP. SCP 260 returns an Authorize Term message to the SSP so call proceeds as 261 normal. 263 Communicating subscriber's choice to the SCP. 264 o ICW UAS returns a SIP "DECLINE" (for normal SSP treatment) or "OK" 266 January 1999 268 (for connecting the call). 269 o ICW Server passes along the SIP message to the SCP 271 Choice: Drop Modem, take call. 272 o ICW UAS causes Modem to drop. 273 o SCP instructs switch to continue with the call (Authorize Term). 274 o Switch connects Calling Party to Subscriber line causing the phone 275 to ring. 277 Choice: Send to Voice Mail. 278 o SCP sends Authorize Term message to switch to deliver the call to 279 the subscriber's line. 280 o SSP detects Busy and uses standard Call Forwarding on Busy to send 281 to Voice Mail 283 Experiences in using SIP for ICW Project 285 The biggest advantage to using SIP in the ICW project was its 286 ASCII-based nature and a concise set of messages. We were able to 287 get a bare-bones SIP server running in a good part of a week. SIP is 288 geared towards Internet protocol services; ICW is a prime example of 289 such a service. SIP's semantics lend themselves very efficiently to 290 the semantics of the ICW service. SIP has a very rich set of 291 response codes that we were able to tailor to the various ICW states, 292 such as the user accepting a call, declining a call, redirecting a 293 call to a new location, or simply not being on the PC when the call 294 notification arrived. Another advantage of SIP is that a SIP-based 295 architecture is easily explained to even those who do not possess an 296 in-depth understanding of Internet in general and IP protocols in 297 particular. Various SIP entities like SIP User Agent Server, Proxy 298 Server, Redirect Server, etc. lend themselves to a very extensible 299 architecture. 301 The disadvantages of SIP are few; one of them being its constant 302 state of flux. During ICW development, the SIP draft RFC changed no 303 less then 3 minor versions. This made it somewhat difficult to agree 304 on a standard. However, this disadvantage will be mitigated in the 305 future when the SIP draft becomes a Draft Standard. The other big 306 disadvantage was driven by the general lack of support for database 307 queries. For instance, an SCP would like to authoritatively know if 308 a user was on the Internet before sending him/her the call 309 notification. However, the SIP message set did not support general 310 querying capabilities for this purpose. We ended up using the SIP 311 OPTIONS message for this purpose, even though the draft mandates that 312 OPTIONS message is used primarily for capability set negotiations. 313 Finally, the SIP RFCs are becoming more complex with each new 314 revision. We believe that while adding features is critical, it 315 would be in the best interest to maintain the simplicity of SIP for 316 rapid development, debugging, and deployment. 318 Security Considerations 320 January 1999 322 ICW communications between the PC and the ICW Server may travel over 323 the Internet. Thus it is essential to provide encryption for the 324 communications. In addition to encryption, and to make sure that the 325 PC belongs to a registered subscriber, it is also necessary to 326 provide authentication of both the end points; i.e. ICW Server and 327 the PC. ICW security has been designed to authenticate both end 328 points and if the authentication succeeded, encrypt the 329 communications (control channel) using a symmetric key. This key is 330 provisioned in the ICW Server database as well as generated at the 331 subscriber's end-point (the PC) when the software is initially 332 installed. In the future, migration of the ICW security 333 infrastructure to SSL is envisioned. 335 ICW Security Requirements are, assentially, the same as PINT Security 336 Requirements outlined in [4]: 338 o Peer entity authentication to allow a communicating entity to prove 339 its identity to another in the network. Two types of peers should be 340 recognized for the purposes of this project: end-user and the Web 341 server, and Web server and SN. Between the end-user and Web server 342 the authentication could be accomplished by means of the user name 343 and password combination. In addition, encrypted communications 344 could be used in this case. Same could be used between the Web 345 server and SN, but it is proposed that additional security be 346 accomplished by replicating a part of the server's data base relevant 347 to the business providing the service. 349 o Non-repudiation to account for all operations in case of doubt or 350 dispute. This could be achieved by logging all the information 351 pertinent to the Web transaction. In addition, the PSTN network will 352 maintain its own account of the transaction for generating bills. 354 o Confidentiality to avoid disclosure of information without the 355 permission of its owner. Although this is an essential requirement, 356 it is not particular to the proposed project. 358 o End-user profile verification to verify if the end user is 359 authorised to use a service. 361 In the course of the project execution, additional requirements are 362 likely to arise and many more specific security work items are likely 363 to be proposed and implemented. 365 Some of the ICW-specific security considerations: 366 o Hacking is a threat to any Service Provider (PSTN, Intranet, 367 Internet). It is real danger - phone companies are common targets 368 o Strong Firewall solutions are needed 369 o Fraudulent Subscription is one of the threats 370 o Existing mechanisms applied to the Internet can be implemented 371 o Stealing a Call is a new type of security threat 373 January 1999 375 o Denial of telephone service attack is possible 376 o Encrypted password protection can be used as one of the possible 377 solutions. 379 5. References 381 [1] J. Postel, RFC 1543, "Instruction to RFC Authors". October 1993 383 [2] ITU-T Q.12xx Recommendation Series, Geneva, 1995. 385 [3] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The 386 Intelligent Network Standards, their Application to Services". 387 McGraw-Hill, 1996. 389 [4] M. Krishnaswamy, "PSTN-Internet Internetworking - An Architecture 390 Overview", Internet Draft 392 [5] H. Schulzrinne, "SIP for Click-To-Dial-Back and Third-Party 393 Control", Internet Draft 395 [6] S. Petrack, "IP Access to PSTN Services: Basic Service 396 Requirements, Definitions, and Architecture", Internet Draft 398 [7] Handley, Schulzrinne, Schooler, Rosenberg, "SIP: Session 399 Initiation Protocol", Internet Draft 401 6. Authors' Address 402 Alec Brusilovsky 403 E-mail: abrusilovsky@lucent.com 404 Telephone: +1-630-713-8401 405 Fax: +1-630-713-5840 406 Lucent Technologies 407 263 Shuman Blvd. 408 Naperville, IL 60566 USA 410 Eric Gausmann 411 E-mail: egausmann@lucent.com 412 Telephone: +1-630-713-5361 413 Fax: +1-630-713-5840 414 Lucent Technologies 415 263 Shuman Blvd. 416 Naperville, IL 60566 USA 418 Vijay Gurbani 419 E-mail: vkg@lucent.com 420 Telephone: +1-630-224-0216 421 Fax: +1-630-713-5840 422 Lucent Technologies 423 263 Shuman Blvd. 425 January 1999 427 Naperville, IL 60566 USA 429 Ajay Jain 430 E-mail: ajayjain@lucent.com 431 Telephone: +1-630-979-5218 432 Fax: +1-630-713-5840 433 Lucent Technologies 434 263 Shuman Blvd. 435 Naperville, IL 60566 USA 437 Glossary 439 AIN Advanced Intelligent Network 440 API Application Program Interface 441 DN Destination Number 442 GSTN Global Switched Telephone Network 443 ICW Internet Call Waiting 444 IN Intelligent Network 445 IP Intelligent Peripheral 446 PSTN Public Switched Telephone Network 447 POTS Plain Old Telephone Service 448 SCP Service Control Point 449 SIP Session Initiation Protocol 450 SN Service Node 451 SMS Service Management System 452 TAT Terminating Attempt Trigger 453 UAS User Agent Server (SIP Terminology) 454 VoIP Voice over IP (Internet Protocol) 456 7. Acknowledgments 458 The authors would like to acknowledge Igor Faynberg, Jenny Huang, 459 Jack Kozik, Hui-Lan Lu, Bill Opdyke, Jonathan Rosenberg, Henry 460 Sinnreich, Doug Varney and Kumar Vemuri for their insightful comments 461 presented at the working discussions that lead to the creation of 462 this document. Our special thank you is going to John Stanaway for 463 being instrumental in utilizing SIP for the ICW project. 465 8. Appendix (IN Tutorial and Figure A) 467 Intelligent Network (IN), excerpt from [4] 469 IN ([2], [3]) is an architectural concept that provides for the 470 real-time execution of network services and customer applications in 471 a distributed environment consisting of interconnected computers and 472 switching systems. Also included in the scope of IN are systems and 473 technologies required for the creation and management of services in 474 this distributed environment. 476 January 1999 478 In PSTNs, user's telephone terminals and fax machines are connected 479 to telephone switches. The switches (which can be Central 480 Offices--for wireline communications and Mobile Switching Centers 481 (MSCs)--for wireless communications) are specialized computers 482 engineered for provision of services to the users. The switches 483 themselves are interconnected in two ways: 1) through trunks on which 484 the voice is carried and 2) through a specialized fault-tolerant data 485 communications network, which is (principally) used for call setup 486 and maintenance. This network is called (after the ITU-T standard 487 protocol suite that it uses) Signalling System No. 7 (SS7). In 488 addition, the switches are connected to general purpose computers 489 that support specialized applications (called Operations Systems) 490 whose role includes network management, administrative functions 491 (e.g., billing), maintenance, etc. Operation systems are not 492 connected to the switches through the SS7 network, which is, again, 493 engineered only for set-up and real time maintenance of calls. In 494 most cases, X.25 protocol is used for communications between 495 operations systems and switches. Even a simple two-party call in 496 most cases involves several switches, which may also be located in 497 different PSTNs. To this end, the switches alone comprise a complex 498 distributed processing environment. As far as the end users are 499 concerned, the switches are ultimately responsible for delivering 500 telecommunications services. Certain elementary services (such as 501 provision of the dial tone, ringing the called line, and establishing 502 a connection between two users) are called basic services, and all 503 switches can presently cooperate in delivering them to end users. 505 In addition, a multitude of services (such as Freephone [a.k.a. 800 506 number in North America], Conference Calling, Call Forwarding, and 507 many others) require much more than basic call processing. Such 508 services are called Supplementary Services, and their implementation 509 requires that specialized applications (called Service Logic) be 510 developed. Developing switch-based service logic for each 511 supplementary service would be an extremely expensive (if at all 512 possible) task, which--in the presence of multiple switch 513 vendors--would also require an extensive standardization effort. 515 The IN architecture is the alternative which, in a nutshell, 516 postulates using a network-wide server (called Service Control 517 Function [SCF]). The SCF executes service logic and instructs the 518 switches on how to complete the call. A switch is involved only in 519 executing the basic call process, which is interrupted (at 520 standardized breakpoints called triggers) when specialized service 521 logic needs be executed. On encountering such a breakpoint, the 522 switch issues a query to the SCF and waits for its instruction. In 523 addition (and this is essential for supporting the services described 524 in section 2), the SCF may initiate a call on its own by instructing 525 switches to establish necessary connections among themselves and to 526 the call parties. 528 January 1999 530 Physically, the SCF may be located in either stand-alone general 531 purpose computers called Service Control Points (SCPs) or specialized 532 pieces of equipment called Service Nodes (SNs). In addition to 533 executing service logic, a service node can perform certain 534 switching functions (such as bridging of calls)as well as a set of 535 specialized functions (such as playing announcements, voice 536 recognition and text-to-speech conversion). An important distinction 537 between an SCP and SN is that the former is connected to switches via 538 the SS7 network while the latter communicates with the switch via 539 Integrated Services Digital Network (ISDN) Primary or Basic Rate 540 Interfaces (PRI or BRI), which combine both the signaling and voice 541 paths. With the present state of IN standardization, in principle, 542 either an SCP or SN could be connected to an Internet server in order 543 to support the services outlined in section two. To further narrow 544 the scope of work so as to produce tangible results as soon as 545 possible, the proposed project specifically addresses only 546 interconnection between a server and SN. 548 Within the IN architecture, the relevant administration of the 549 network entities (i.e., setting the triggers in the switches, 550 transferring externally developed service logic to SCPs and SNs, and 551 maintaining the network databases with the customer-related data) is 552 performed by a specialize Operation System called Service Management 553 System (SMS). 555 January 1999 557 Figure A 558 |F| 559 |i| 560 +---------------------+ ============= |r| 561 | +-------+| || || SIP |e| +--------+ 562 | PC Access | ICW || || Internet |+-..-..|w|-..-..-| ICW | 563 | o..........+ UAS || || || |a| | Server | 564 | +--+----+| =========+=== |l| +---+----+ 565 | Voice Access : | | |l| | 566 | 0------------I: | : _____:_____ 567 | I: | | SIP Firewall 568 | I: | : ----------- 569 | I: | | | 570 | I: | +---+---+ : 571 | I: | | ISP | | 572 |ICW I: | +---+---+ : 573 |Subscriber I: | | +-------+ +---+---+ 574 +--------------I:-----+ PPP : | SMS |---| SCP | 575 I:......................+ | +-------+ +---+---+ 576 L----------------------+: : s 577 POTS =======I:=|========== | 578 || I: : || =====s==== 579 || I: | || || || 580 || +++-+---+ || || SS7 || 581 o---------------------------++-----| SSP | || ||Network|| 582 Calling Party || +---+---+ || =====s==== 583 (Voice Access) || s P S T N || | 584 ========= | ========= SS7 s 585 s-s-s-s-s-s-s-s-s-s-s-s-s+ 586 Legend: Signaling 587 ..-..- - SIP (over IP) 588 s-s-s - SS7 signaling links 589 ----- - POTS connection 590 ..... - PPP connection