idnits 2.17.1 draft-ietf-pint-inweb-00.txt: 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-16) 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 == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 20 instances of too long lines in the document, the longest one being 6 characters in excess of 72. 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 1997) is 9649 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) -- Looks like a reference, but probably isn't: 'SCF' on line 617 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1902 (ref. '4') (Obsoleted by RFC 2578) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft M. Krishnaswamy 3 PSTN and Internet Internetworking Working Group Bell Laboratories, 4 Lucent Technologies 5 Expire in six months November 1997 7 PSTN-Internet Internetworking - An Architecture Overview 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 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 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 This memo provides information for the Internet community. This memo 30 does not specify an Internet standard of any kind. Distribution of 31 this memo is unlimited. 33 Abstract 35 This memo is submitted as input to the draft PINT (PSTN and Internet 36 Internetworking) Informational RFC. This document describes an 37 internetworking architecture of the Public Switched Telephone Network 38 (PSTN) and the Internet based on the Lucent prototype. This 39 architecture enables access to PSTN services from the Internet. The 40 four basic PSTN services that could be made available to an Internet 41 User are described. We have used the World Wide Web as an example to 42 show how these PSTN services can be seamlessly integrated into the 43 Internet. Next a Service Support Transport Protocol for reliable 44 transfer of service request from the Internet to the PSTN network is 45 described. A simple Management Information Base (MIB) that is used 46 for uploading information and performing authentication checks is 48 PSTN-Internet Internetworking Architecture November 1997 50 then described. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . 2 55 2. Service Description . . . . . . . . . . . . . . . . 3 56 3. Overall Interconnection Architecture . . . . . . . . 4 57 4. Interfaces Relevant to the Work . . . . . . . . . . 6 58 5. Role of the Web server and IN entities . . . . . . . 6 59 6. A Click-to-Dial-Back Service Scenario . . . . . . . 7 60 7. SSTP Information Exchange . . . . . . . . . . . . . 7 61 8. Web server - SMS Interface and SNMP MIB . . . . . . 10 62 9. Security Considerations . . . . . . . . . . . . . . 11 63 10. References . . . . . . . . . . . . . . . . . . . . . 12 64 11. Authors' Address . . . . . . . . . . . . . . . . . . 12 65 12. Appendix A . . . . . . . . . . . . . . . . . . . . . 14 67 1. Introduction 69 Interconnection of the Internet and Public Switched Telephone 70 Networks would provide more effective media to a user than either 71 network type can do presently. Interworking of the Internet and 72 PSTNs, based on open well-defined interfaces, will promote 73 interoperability of both the networks and systems built by different 74 vendors. 76 Based on the prototype developed in Bell Laboratories, this document 77 describes a specific example of basic PSTN services that could be 78 accessed from World Wide Web, the most popular Internet 79 application/service. The Service Support Transport Protocol used to 80 transfer the PSTN service requests from the Web server to the PSTN 81 network is based on TCP so as to provide reliable communication 82 between the two network entities. 84 On the PSTN side we have considered only one architecture, IN 85 (Intelligent Network) in our case. IN has been standardized 86 internationally by the International Telecommunications Union 87 Telecommunications Standardization Sector (ITU-T) and is being widely 88 implemented in the telecommunications networks around the world. 89 Again within the IN, our document describes the interconnection to 90 the two specific IN entities, Service Node (SN) and the Service 91 Management System (SMS). A brief introduction to the Intelligent 92 Network architecture is provided in Appendix A for those not familiar 93 with the IN. 95 A specific example of a World Wide Web User browsing the Web pages 96 and clicking on a hyper-text link in a content provider's page to 98 PSTN-Internet Internetworking Architecture November 1997 100 place a PSTN service call is used throughout this document. 102 A Management Information Base for uploading Web content provider 103 profiles to the SMS and providing service authentication and 104 verification is next described. 106 Finally we briefly mention about some of the security issues involved 107 in the internetworking of the PSTN and Internet. 109 2. Service Description 111 The common denominator of the services introduced in this section is 112 bringing telephone services (provided by PSTNs) to Internet users. 113 Successful interworking of the Internet and Public Switched Telephone 114 Network (PSTN) should enable integration of PSTN services (e.g., a 115 telephone call) with those offered by the Internet through the 116 World-Wide Web. Examples of such services are Click-to-Dial-Back, 117 Click-to-Fax, Click-to-Fax-Back, and Voice-Access-to-Content, and 118 they can be briefly described as follows: 120 With the Click-to-Dial-Back service, a Web user can initiate a PSTN 121 call by clicking a button during a Web session. Such a call can be 122 either incoming or outgoing. (An example of the former is when a 123 user, while browsing through a catalogue, clicks the button inviting 124 a sales representative to call him or her.) 126 With the Click-to-Fax service, a Web user can send a fax by 127 clicking a button during a Web session. 129 With the Click-to-Fax-Back service, a Web user can request (and 130 subsequently receive) a fax by clicking a button during a Web 131 session. 133 With the Voice-Access-to-Content service, a Web user can have 134 access to the Web content by telephone. The content is converted to 135 speech and transmitted to the user on a telephone line. 137 (In all of the above four cases the service request and the data 138 thereof (for Click-to-Fax, Click-to-Fax-Back and Voice-Access-to- 139 Content) are sent from the web server to the PSTN equipment). 141 PSTN-Internet Internetworking Architecture November 1997 143 FIGURE 1: 145 O End Users (PC Access) O End Users (Voice Access) 146 | | 147 | | 149 ^ ^ 150 --|--------------------------------------|---- 151 | | 152 | Content Service Providers | Network Operators 153 / / 154 ============================= ======================================= 155 || World Wide Web/Internet || || Public Switched Telephone Network || 156 ============================= ======================================= 158 3. Overall Interconnection Architecture 160 A somewhat general view of the proposed project is presented in 161 Figure 1. The figure distinguishes the two types of end-users: 1) the 162 Web users, whose PCs (or other Internet access devices) are connected 163 to the Internet, and 2) the telephone users, whose telephones or fax 164 machines are connected to PSTNs. In this context, the proposed 165 internetworking involves interconnection of Internet service 166 providers and network operators (who own PSTNs). 168 PSTN-Internet Internetworking Architecture November 1997 170 Figure 2: 172 Web Users 173 ____________ 174 O -------------------------- | Internet |------------------------ 175 ------------ | 176 | 177 | 178 ---------------- -------------- -------------- 179 | Service Node | D | Service | B | Web Server | 180 | (SN) |------------| Management |------------------| | 181 | | |System (SMS)| | | 182 | | -------------- | | 183 | | A . | | 184 | |--------------------------------------------| | 185 ---------------- . ------------- 186 | | . . 187 | I | C . H . E 188 | | ........................... 189 ----------- --------- G --------- 190 |Mobile | |Central|-----------------------------------------|Service| 191 |Switching| |Office | |Control| 192 | Center | --------- F |Point | 193 | |-----|---------------------------------------------| | 194 ----------- | | (SCP) | 195 | | --------- 196 | | 197 O O 199 Mobile Wireline PSTN 200 Users Users 202 In Figure 2 we identify the scope of our work covered in this 203 document in an overall PSTN/Internet interworking architecture. 205 The PSTN users are depicted connected to both the central office via 206 wireline and mobile switching center via wireless communications. The 207 IN entities that contain the Service Control Function (i.e., the SN 208 and SCP) are shown with their respective interfaces to, first of all, 209 the switches. Specifically, the ISDN-based interfaces from the SN to 210 the MSC and center office are respectively marked I and C; the SS7- 211 based interfaces from the SCP to the MSC and center office are 212 respectively marked F and G. (The latter two interfaces are depicted 213 with the dotted line because they are not within the scope of this 214 work). Finally, the SMS is depicted together with its respective 215 interfaces to the SN (D) and SCP (H). (Again, the interface H is 217 PSTN-Internet Internetworking Architecture November 1997 219 depicted with the dotted line because it is not within the scope of 220 the work.) 222 On the Internet side, Figure 2 exhibits a Web user connected to the 223 Web server. The server can have two interfaces: interface A to the SN 224 and interface B to the SMS. (As before, a feasible, but not 225 considered within the scope of this work, interface E to the SCP is 226 depicted using the dotted line.) 228 4. Interfaces Relevant to our work 230 Referring to Figure 2, the relevant interfaces are A, B, D, I, and C. 232 The interfaces between the SN and switches (interfaces I and C), as 233 well as the interface between the SN and SMS (interface D) have been 234 studied in ITU-T Study Group 11; 236 In our work interface A is based on SSTP (Service Support Transport 237 Protocol) carried on top of TCP/IP and the interface B is based on 238 SNMP Ver 2. 240 5. Role of the Web server and IN entities 242 Web Server 244 The web server stores the profiles of content providers. The profile 245 should include information such as content provider ID, telephone 246 number and fax number. It may also include service logic that 247 specifies, for example, the telephone (or fax) number to be reached 248 based on time of the day, day of the week, or geographical location 249 of the user, and the conditions to accept the charge of the calls. 251 The web server may also store the profiles of users who are pre- 252 registered. Similar to the content provider profile, the user profile 253 include information such as user name, password, telephone number, 254 and fax number. The last two pieces of information can also be linked 255 with time of the day and day of the week so the user can be reached 256 at the appropriate telephone (or fax) number accordingly. 258 Service Node 260 Situated in the PSTN, the SN, like the SCP, performs the service 261 control function [1] [2]. It executes service logic and instructs 262 switches on how to complete a call. Unlike the SCP, the SN also 263 performs certain switching functions (like bridging of calls) as well 265 PSTN-Internet Internetworking Architecture November 1997 267 as a set of specialized functions (like playing announcements, voice 268 recognition and text-to-speech conversion). 270 Another distinction between the SN and SCP is that the former is 271 connected to switches via the Integrated Services Digital Network 272 (ISDN) Primary or Basic Rate Interfaces (PRI or BRI) while the latter 273 is connected to switches via the Signaling System 7 (SS7) network. As 274 such, there are fewer security concerns connecting the SN than SCP to 275 the web server. 277 Service Management System 279 The SMS performs administration and management of service logic and 280 customer-related data on the SN. It is responsible for the 281 replication of content provider profiles and provision of these data 282 on the SN. These functions are not performed in real time. 284 6. A Click-to-Dial-Back Service Scenario 286 A Web user, who has simultaneous access to the Web and telephone 287 services (this can be achieved, for example, by having an ISDN 288 connection), is browsing through a sales catalogue and deciding to 289 speak to a sales representative. 291 When the Web user clicks a button inviting a telephone call from the 292 sales office, the Web server sends a message to the SN over the A 293 interface, thus crossing the Internet-to-PSTN boundary. By matching 294 the information received from the Web server with the content 295 provider profile that had been previously loaded and activated by the 296 SMS over the D interface, the SN recognizes the signal. 298 At this point, the SN calls the Web user. The user answers the call, 299 hears an announcement (e.g., "Please wait, while we are connecting 300 you to the sale agent") and is waiting to be connected to the sale 301 agent. Then the SN invokes service logic as indicated in the 302 profile. The execution of this logic selects an appropriate sales 303 agent to call based on the time of the day. It is 8 P.M. in New York 304 where the Web user is located, and the New York sales office has 305 closed. But the San Francisco office is still open, and so the SN 306 selects an appropriate central office, establishes the connection 307 (the interface C) to this central office, verifies that there is at 308 least one sales agent line that is free and instructs the switch to 309 call the agent. Finally, the SN bridges the two calls and establishes 310 a two-party call between the sales agent and the Web user. 312 7. SSTP Information Exchange 314 PSTN-Internet Internetworking Architecture November 1997 316 The protocol is for communications between the SN (or SCP) and web 317 server. It is of a request/response type running on top of a reliable 318 transport layer, such as TCP. The web server sends a request to the 319 SN to invoke a service and the SN responds with a message indicating 320 either success or failure. Note that the protocol effectively engages 321 the service control function [1] [2] that is common to both the SN 322 and SCP; for simplicity only the SN is mentioned. 324 A. Web Server to Service Node 326 In this direction, three kinds of messages may be sent: the 327 Transaction Initiator message, the Data Message, and the End of Data 328 message. 330 The latter two messages are needed if the service to be invoked 331 involves data (e.g., click-to-fax, click-to-fax-back and voice- 332 access-to-content). This is so designed to handle the varying size 333 of data and to ensure that the size of each stream is within the 334 allowable size of the underlying transport packet data unit (imposed 335 by some implementations of TCP/IP). 337 a. Transaction Initiator 339 This message provides all the necessary information but data for 340 invoking a service. It includes the following information elements: 342 + Transaction ID, which uniquely specifies a service request. The 343 same transaction ID should be used for all the accompanying data- 344 related messages, if the service request involves data. One way for 345 generating unique transaction IDs is to concatenate the information: 346 date, time, web server ID (uniquely assigned for each one connected 347 to the SN), and transaction sequence number (a cyclic counter 348 incremented for each service request). 350 + Service ID, which specifies the service to be invoked. The service 351 may be click-to-dial, click-to-fax, click-to-fax-back or voice- 352 access-to-content. 354 + Content Provider ID, which uniquely represents the content 355 provider. This information is the key to accessing the content 356 provider's service logic and data on the SN. 358 + Content Provider Directory Number, which is the telephone or fax 359 number of the content provider to be called through the PSTN. 361 + User Directory Number, which is the telephone or fax number of the 362 user requesting the service. 364 PSTN-Internet Internetworking Architecture November 1997 366 + Billed Party, which specifies the party (either the user or content 367 provider), to be billed. 369 In addition, optional parameters may be sent from the web server to 370 the SN. For example, a retry parameter may be sent to specify the 371 number of times the SN will attempt to complete a service request 372 upon failure before the transport connection times out. 374 b. Data Message 376 This message provides the (encapsulated) user data part of a service 377 request. For example, in the case of click-to-fax-back such data are 378 the content to be faxed to the user. Each message is composed of the 379 transaction ID and a data segment. The transaction ID must be the 380 same as that of the transaction initiator part first invoking the 381 service. 383 c. End of Data Message 385 This message contains the transaction ID and the end of data 386 delimiter. The transaction ID is the same as that of the relevant 387 transaction initiator message. 389 B. Service Node to Web Server 391 The SN must respond to a service request from the web server. The 392 response message consists of the information elements: 394 transaction ID, service type, result, time, and error code. 396 + Transaction ID, which is the same as that of the original service 397 request. 399 + Service Type, which is the same as that of the original service 400 request. 402 + Result, which is either success or failure. 404 + Time, which indicates the time of the day completing the request. 406 + Error Code, which gives the reason for failure. Possible reasons 407 for failure are content provider telephone (or fax) busy, content 408 provider telephone (or fax) no answer, user telephone busy, user 409 refusal to complete, user no answer, nuisance control limit reached, 410 and content provider telephone (or fax) not in the SN database. 412 PSTN-Internet Internetworking Architecture November 1997 414 8. Web Server - SMS Interface and SNMP MIB 416 This interface is needed to upload the content provider profile from the 417 web server to the SMS and manage the information against any possible 418 corruption. The SN verifies the Content Provider ID and the Content 419 Provider Directory Number sent by the Web Server with the content 420 provider profile preloaded from the SMS. 422 The content provider profile is based on ASN.1 structure and we use SNMP 423 to set/get the object identifiers in the SMS database. [3] [4] 425 Following is an example of the simple MIB available on the SMS. 427 inwebContProviderTable OBJECT-TYPE 428 SYNTAX SEQUENCE OF InwebContProviderEntry 429 MAX-ACCESS not-accessible 430 STATUS current 431 DESCRIPTION 432 " A table containing Content Provider profiles " 433 ::= { inweb 1} 435 inwebContProviderEntry OBJECT-TYPE 436 SYNTAX InwebContProviderEntry 437 MAX-ACCESS not-accessible 438 STATUS current 439 DESCRIPTION 440 " A conceptual row of the inweb. Each row 441 contains profile of one Content Provider" 442 INDEX { inwebSmsNumber } 443 ::= { inwebContProviderTable 1 } 445 InwebContProviderEntry ::= SEQUENCE { 446 inwebSmsNumber Integer32, 447 inwebContentProviderId Integer32, 448 inwebContentProviderPhoneNumber Integer32, 449 inwebContentProviderFaxNumber Integer32 450 } 452 inwebSmsNumber OBJECT-TYPE 453 SYNTAX Integer32 454 MAX-ACCESS read-only 455 STATUS current 456 DESCRIPTION 457 " Serial number of the SMS - used for SNMP indexing " 458 ::= { inwebContProviderEntry 1 } 460 inwebContentProviderId OBJECT-TYPE 462 PSTN-Internet Internetworking Architecture November 1997 464 SYNTAX Integer32 465 MAX-ACCESS read-create 466 STATUS current 467 DESCRIPTION 468 " A number that uniquely identifies each Content Provider " 469 ::= { inwebContProviderEntry 2 } 471 inwebContentProviderPhoneNumber OBJECT-TYPE 472 SYNTAX Integer32 473 MAX-ACCESS read-create 474 STATUS current 475 DESCRIPTION 476 " Content Provider's Phone Number " 477 ::= { inwebContProviderEntry 3 } 479 inwebContentProviderFaxNumber OBJECT-TYPE 480 SYNTAX Integer32 481 MAX-ACCESS read-create 482 STATUS current 483 DESCRIPTION 484 " Content Provider's Fax Number " 485 ::= { inwebContProviderEntry 4 } 487 9. Security Considerations 489 We only address the security issues concerning the interface between the 490 Web server and the SN (or SCP). Those concerning the interface between 491 the user and the Web server are not specific to this proposal and won't 492 be discussed. The interface between the Web server and SMS is based on 493 SNMP and will rely on its own security features. 495 + Secure Communication Links 497 If the Network Operator (PSTN provider) is also Web Service provider, 498 the Web Server and SN/SMS will be over a corporate intranet. This 499 network is almost always protected by the corporation's firewall and so 500 can be deemed secure. 502 Nevertheless, if the Network Operator and the Web Service provider are 503 different corporations, then it is likely that there may not exist a 504 dedicated secure communication link between the Web Server and SN/SMS. 505 The communications may be required to be carried over Internet. This 506 raises serious security considerations. One possible solution is to use 507 Virtual Private Networks (VPN). VPNs features support authentication of 508 the calling and called parties and encryption of the messages sent over 509 unsecure links (Internet). 511 PSTN-Internet Internetworking Architecture November 1997 513 + Non-Repudiation 515 All transactions will be logged on both the Web server and the service 516 node to account for all operations in case of doubt or dispute. The log 517 information on the SN can also be used to generate bills. 519 + Malicious Requests of Users 521 A user may make repeated requests to a content provider directory number 522 maliciously. This can be handled by setting a Nuisance Control Limit 523 (NCL) on either the SN or the Web server or both. The NCL may be based 524 on requests from the same user within a, for example, 15 minute period. 526 A user may also attempt to request a call from a directory number other 527 than that of a content provider. Such an attempt can be handled by 528 verifying the directory number (and the content provider ID) against the 529 database on the SN containing all the content provider information. If 530 the directory number (or the content provider ID) is not in the 531 database, the request will be rejected. 533 10. References 535 [1] ITU-T Q.12xx Recommendation Series, Geneva, 1995. 537 [2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The 538 Intelligent Network Standards, their Application to Services". McGraw- 539 Hill, 1996. 541 [3] Information processing systems - Open Systems Interconnection - 542 Specification of Abstract Syntax Notation One (ASN.1), International 543 Organization for Standardization. International Standard 8824, 544 (December, 1987). 546 [4] McCloghrie, K., Editor, "Structure of Management Information for 547 version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 548 January 1996. 550 11. Author' Address 552 Murali Krishnaswamy 553 E-mail: murali@bell-labs.com 554 Telephone: +1-732-949-3611 555 Fax: +1-732-949-3210 557 PSTN-Internet Internetworking Architecture November 1997 559 Bell Laboratories 560 Room 2G-527A 561 101 Crawfords Corner Road 562 Holmdel, NJ 07733-3030 563 USA 565 PSTN-Internet Internetworking Architecture November 1997 567 12. Appendix A - Intelligent Network (IN) 569 IN ([1], [2]) is an architectural concept that provides for the real- 570 time execution of network services and customer applications in a 571 distributed environment consisting of interconnected computers and 572 switching systems. Also included in the scope of IN are systems and 573 technologies required for the creation and management of services in 574 this distributed environment. 576 In PSTNs, user's telephone terminals and fax machines are connected to 577 telephone switches. The switches (which can be Central Offices--for 578 wireline communications and Mobile Switching Centers (MSCs)--for 579 wireless communications) are specialized computers engineered for 580 provision of services to the users. The switches themselves are 581 interconnected in two ways: 1) through trunks on which the voice is 582 carried and 2) through a specialized fault-tolerant data communications 583 network, which is (principally) used for call setup and maintenance. 584 This network is called (after the ITU-T standard protocol suite that it 585 uses) Signalling System No. 7 (SS7). In addition, the switches are 586 connected to general purpose computers that support specialized 587 applications (called Operations Systems) whose role includes network 588 management, administrative functions (e.g., billing), maintenance, etc. 589 Operation systems are not connected to the switches through the SS7 590 network, which is, again, engineered only for set-up and real time 591 maintenance of calls. In most cases, X.25 protocol is used for 592 communications between operations systems and switches. 594 Even a simple two-party call in most cases involves several switches, 595 which may also be located in different PSTNs. To this end, the switches 596 alone comprise a complex distributed processing environment. As far as 597 the end users are concerned, the switches are ultimately responsible for 598 delivering telecommunications services. Certain elementary services 599 (such as provision of the dial tone, ringing the called line, and 600 establishing a connection between two users) are called basic services, 601 and all switches can presently cooperate in delivering them to end 602 users. 604 In addition, a multitude of services (such as Freephone [a.k.a. 800 605 number in North America], Conference Calling, Call Forwarding, and many 606 others) require much more than basic call processing. Such services are 607 called Supplementary Services, and their implementation requires that 608 specialized applications (called Service Logic) be developed. Developing 609 switch-based service logic for each supplementary service would be an 610 extremely expensive (if at all possible) task, which--in the presence of 611 multiple switch vendors--would also require an extensive standardization 612 effort. 614 PSTN-Internet Internetworking Architecture November 1997 616 The IN architecture is the alternative which, in a nutshell, postulates 617 using a network-wide server (called Service Control Function [SCF]). The 618 SCF executes service logic and instructs the switches on how to complete 619 the call. A switch is involved only in executing the basic call process, 620 which is interrupted (at standardized breakpoints called triggers) when 621 specialized service logic needs be executed. On encountering such a 622 breakpoint, the switch issues a query to the SCF and waits for its 623 instruction. In addition (and this is essential for supporting the 624 services described in section 2), the SCF may initiate a call on its own 625 by instructing switches to establish necessary connections among 626 themselves and to the call parties. 628 Physically, the SCF may be located in either stand-alone general purpose 629 computers called Service Control Points (SCPs) or specialized pieces of 630 equipment called Service Nodes (SNs). In addition to executing service 631 logic, a service node can perform certain switching functions (such as 632 bridging of calls)as well as a set of specialized functions (such as 633 playing announcements, voice recognition and text-to-speech conversion). 635 An important distinction between an SCP and SN is that the former is 636 connected to switches via the SS7 network while the latter communicates 637 with the switch via Integrated Services Digital Network (ISDN) Primary 638 or Basic Rate Interfaces (PRI or BRI), which combine both the signaling 639 and voice paths. With the present state of IN standardization, in 640 principle, either an SCP or SN could be connected to an Internet server 641 in order to support the services outlined in section two. To further 642 narrow the scope of work so as to produce tangible results as soon as 643 possible, the proposed project specifically addresses only 644 interconnection between a server and SN. 646 Within the IN architecture, the relevant administration of the network 647 entities (i.e., setting the triggers in the switches, transferring 648 externally developed service logic to SCPs and SNs, and maintaining the 649 network databases with the customer-related data) is performed by a 650 specialize Operation System called Service Management System (SMS).