idnits 2.17.1 draft-ietf-pint-pre-implement-02.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-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. ** Bad filename characters: the document name given in the document, 'draft-IETF-pint-pre-implement-02', contains other characters than digits, lowercase letters and dash. == Mismatching filename: the document gives the document name as 'draft-IETF-pint-pre-implement-02', but the file name used is 'draft-ietf-pint-pre-implement-02' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 52 longer pages, the longest (page 14) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 53 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5.2.2.7 Security Considerations' ) ** 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 82 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1812 has weird spacing: '... Broker l ...' == Line 1821 has weird spacing: '...unction l ...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 1998) is 9379 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: 'Fax' on line 2519 -- Looks like a reference, but probably isn't: '---' on line 2519 -- Looks like a reference, but probably isn't: '----' on line 485 -- Looks like a reference, but probably isn't: 'MSC' on line 559 -- Looks like a reference, but probably isn't: 'SSP' on line 699 -- Looks like a reference, but probably isn't: 'W3C' on line 791 -- Looks like a reference, but probably isn't: 'W3S' on line 791 -- Looks like a reference, but probably isn't: 'WSA' on line 792 -- Looks like a reference, but probably isn't: 'PktFlt' on line 811 -- Looks like a reference, but probably isn't: 'SCP' on line 2513 -- Looks like a reference, but probably isn't: 'SMS' on line 815 -- Looks like a reference, but probably isn't: '-v-' on line 736 -- Looks like a reference, but probably isn't: 'SSF' on line 2461 -- Looks like a reference, but probably isn't: 'SCF' on line 2456 -- Looks like a reference, but probably isn't: 'SRF' on line 2456 -- Looks like a reference, but probably isn't: 'CBC' on line 761 -- Looks like a reference, but probably isn't: 'CBS' on line 761 -- Looks like a reference, but probably isn't: 'SDF' on line 2456 -- Looks like a reference, but probably isn't: 'CCF' on line 2461 -- Looks like a reference, but probably isn't: 'SDP' on line 2513 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1902 (ref. '5') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 2109 (ref. '6') (Obsoleted by RFC 2965) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PINT Working Group H. Lu (Editor) 2 Internet Draft M. Krishnaswamy 3 Lucent Technologies 4 L. Conroy 5 Roke Manor Research 6 S. Bellovin 7 F. Burg 8 A. DeSimone 9 K. T. Tewani 10 AT&T Labs 11 P. Davidson 12 Nortel 13 H. Schulzrinne 14 Columbia University 15 K. Vishwanathan 16 Isochrome 18 Expires in Six Months August 1998 20 Toward the PSTN/Internet Inter-Networking 21 --Pre-PINT Implementations 23 25 Status of this Memo 27 This document is an Internet-Draft. Internet-Drafts are working 28 documents of the Internet Engineering Task Force (IETF), its areas, 29 and its working groups. Note that other groups may also distribute 30 working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet- Drafts as reference 35 material or to cite them other than as ``work in progress.'' 37 To learn the current status of any Internet-Draft, please check the 38 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 39 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 40 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 41 ftp.isi.edu (US West Coast). 43 This memo provides information for the Internet community. This memo 44 does not specify an Internet standard of any kind. Distribution of 45 this memo is unlimited. 47 Abstract 49 This document contains the information relevant to the development of 50 the inter-networking interfaces underway in the Public Switched 51 Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working 53 Toward PSTN/Internet Inter-Networking May 1998 55 Group. It addresses technologies, architectures, and several (but by 56 no means all) existing pre-PINT implementations of the arrangements 57 through which Internet applications can request and enrich PSTN 58 telecommunications services. The common denominator of the enriched 59 services (a.k.a. PINT services) is that they combine the Internet and 60 PSTN services in such a way that the Internet is used for non-voice 61 interactions, while the voice (and fax) are carried entirely over the 62 PSTN. One key observation is that the pre-PINT implementations, being 63 developed independently, do not inter-operate. It is a task of the 64 PINT Working Group to define the inter-networking interfaces that 65 will support inter-operation of the future implementations of PINT 66 services. 68 Table of Contents 70 1. Introduction ....................................... 3 71 2. Terminology ....................................... 3 72 3. PINT Services ....................................... 4 73 4. Architectural Overview ............................... 5 74 4.1 Public Switched Telephone Network ............... 5 75 4.2 Pre-PINT Systems ............................... 9 76 5. IN-Based Solutions ............................... 18 77 5.1 The Lucent System ............................... 18 78 5.1.1 Roles of the Web Server, Service Node, and SMS ....... 19 79 5.1.2 A Click-to-Dial-Back Service Scenario ............... 20 80 5.1.3 Web Server-Service Node Interface ............... 21 81 5.1.4 Web Server-SMS Interface and SNMP MIB ............... 23 82 5.1.5 Security Considerations ........................... 24 83 5.2 Siemens Web Call Center ........................... 25 84 5.2.1 Service Description ............................... 25 85 5.2.2 Implementation ................................... 27 86 5.2.3 Derived Requirements/Lessons ..................... 32 87 6. Alternative Solutions ............................... 34 88 6.1 The AT&T System ..................................... 34 89 6.1.1 High Level Architecture ............................ 34 90 6.1.2 IP Client to CallBroker Interface .................. 36 91 6.1.3 Protocol ........................................... 36 92 6.1.4 APIs Exposed to the IP Client ..................... 37 93 6.1.5 Voice-Bridge Control API ........................ 37 94 6.2 Simple Computer Telephony Protocol ............... 37 95 6.2.1 Overview ........................................... 37 96 6.2.2 How SCTP Fits in with the Reference PINT Services .. 38 97 7. Session Initiation Protocol--An Emerging Standard .. 39 98 7.1 Overview ....................................... 39 99 7.2 SIP Protocol ....................................... 40 100 7.3 SIP Entities ....................................... 41 101 7.4 Providing Call Control Functionality ............... 41 102 8. Overall Security Considerations ..................... 43 103 9. Conclusion ....................................... 44 104 10. Acknowledgments ................................... 44 105 11. Appendix ....................................... 44 106 11.1 PSTN/IN 101 ....................................... 44 107 11.1.1 Public Switched Telephone Network ............... 44 108 11.1.2 Intelligent Network ............................... 46 110 Toward PSTN/Internet Inter-Networking May 1998 112 11.2 Call Center Features ............................. 49 113 12. References ....................................... 50 115 1. Introduction 117 This document contains the information relevant to the development of 118 the inter-networking interfaces underway in the Public Switched 119 Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working 120 Group. It addresses technologies, architectures, and several (but by 121 no means all) existing pre-PINT implementations of the arrangements 122 through which Internet applications can request and enrich PSTN 123 telecommunications services. The common denominator of the enriched 124 services (a.k.a. PINT services) is that they combine the Internet and 125 PSTN services in such a way that the Internet is used for non-voice 126 interactions, while the voice (and fax) are carried entirely over the 127 PSTN. 129 The organization of the document is as follows. First, the basic 130 terminology and a short "intuitive" description of the PINT services 131 are provided. The rest of the information deals, in one way or the 132 other, with the pre-PINT support of these services where they are 133 used as a benchmark. Thus, an architectural overview common to all 134 present solutions is presented. The flow of the document then 135 divides into two streams: one is dedicated to the Intelligent Network 136 (IN)-based solutions; the other explores alternative means (i.e., 137 CallBroker and Computer-Telephony Integration (CTI) approach). At 138 this point, the emerging standards are explored, in particular, the 139 Session Initiation Protocol (SIP), which promises an elegant solution 140 to the PINT problem. Each of the above developments is addressed in a 141 respective section. The final sections of the document contain the 142 overall security considerations, conclusion, acknowledgments, 143 appendix, and a set of references. The security section summarizes 144 the PINT security requirements derived from the pre-PINT experiences 145 and the appendix presents a tutorial on the PSTN, IN, and Call Center 146 functions. 148 2. Terminology 150 This document uses the following terminology: 152 Authentication -- verification of the identity of a party. 154 Authorization -- determination of whether or not a party has the 155 right to perform certain activities. 157 PINT Gateway -- the PSTN node that interacts with the Internet. 159 User or Customer -- the person who asks for a service request to be 160 issued. In the context of PINT Services, this person will use an 161 Internet host to make his or her request. The term "user" is also 162 used to describe a host originating the PINT service request on 163 behalf of this person. 165 Toward PSTN/Internet Inter-Networking May 1998 167 3. PINT Services 169 This document addresses four services initially identified by the 170 PINT Working Group and presently supported by pre-PINT 171 implementations. These services are: click-to-dial-back, click-to- 172 fax, click-to-fax-back and voice-access-to-content. 174 Note that the word "click" should not be taken literally. It is 175 rather used to point out that initiation of the related services 176 takes place on the Internet, where point and click are the most 177 prevalent user actions. In other words, a service request could 178 originate from any type of IP-based platforms. There is no 179 implication that these services must be implemented by a device 180 within the PSTN or the Internet running a Web server. 182 The common denominator of the PINT services is that they combine the 183 Internet and PSTN services in such a way that the Internet is used 184 for non-voice interactions, while the voice (and fax) are carried 185 entirely over the PSTN. (An example of such a service is combination 186 of a Web-based Yellow Pages service with the ability to initiate PSTN 187 calls between customers and suppliers in a manner described in what 188 follows.) 190 Some of the benefits of using the PSTN are high quality of the voice, 191 an ability to route the call to different locations depending on 192 pre-set criteria (for example, time of the day, day of the week, and 193 geographic location), outstanding security and reliability, and 194 access to flexible, low cost, and secure billing and charging 195 systems. The benefits of using the Internet are the uniform, well- 196 defined, and widely-used interfaces available anywhere, anytime. 198 Click-to-Dial-Back 200 With this service, a user requests (through an IP host) that the PSTN 201 call be established between another party and himself or herself. An 202 important pre-requisite for using this service is that the user has 203 simultaneous access to both the PSTN and Internet. 205 One example of an application of this service is on-line shopping: a 206 user browsing through an on-line catalogue, clicks a button thus 207 inviting a call from a sales representative. Note that (as is the 208 case with the all-PSTN Free-Phone, or "800", service) flexible 209 billing arrangements can be implemented here on behalf of the service 210 provider. In addition (and also similarly to the Free-Phone/800), the 211 PSTN could route the call depending on the time of day, day of week, 212 availability of agents in different locations, and so on. 214 Click-to-Fax 216 With this service, a user at an IP host requests that a fax be sent 217 to a particular fax number. In particular this service is especially 218 meaningful when the fax is to be sent to someone who has only a fax 219 machine (but no access to the Internet). Consider, as an example, a 220 service scenario in which a Web user makes a reservation for a hotel 222 Toward PSTN/Internet Inter-Networking May 1998 224 room in Beijing from a travel service page containing hotel 225 information of major cities around the world. Suppose a specific 226 Beijing hotel chosen by the user does not have Internet connection 227 but has a fax machine. The user fills out the hotel reservation form 228 and then clicks a button sending out the form to the travel service 229 provider, which in turn generates a fax request and sends it together 230 with the hotel reservation form to the PSTN. Upon receiving the 231 request and the associated data, the PSTN translates the data into 232 the proper facsimile format and delivers it to the Beijing hotel as 233 specified in the fax request. 235 Click-to-Fax-Back 237 With this service, a user at an IP host can request that a fax be 238 sent to him or her. (Consider the user of the previous example, who 239 now requests the confirmation from the Beijing Hotel. Another useful 240 application of the service is when size of the information that a 241 user intends to get is so large that downloading it to the user's PC 242 over the Internet will require a long time and a lot of disk space.) 244 Voice-Access-to-Content 246 With this service, a user at an IP host requests that certain 247 information on the Internet be accessed (and delivered) in an audio 248 form over the PSTN, using the telephone as an informational 249 appliance. One application of this service is to provide Web access 250 to the blind. (This may require special resources--available in the 251 PSTN--to convert the Web data into speech.) 253 4. Architectural Overview 255 4.1 Public Switched Telephone Network 257 From an application perspective, Internet nodes are interconnected 258 directly, as shown in Figure 1. When two machines are to communicate, 259 they will have the address of the destination end system, and will 260 send network level datagrams, assuming that the underlying 261 infrastructure will deliver them as required. 263 _____ 264 __ _____/ \_____ 265 [__] / \ 266 [----]-.-.-.-. Internet .-. 267 \_____ _______/ | 268 __ \__./ __ . 269 [__] / [__] | 270 [----]-. [----]-. 272 Key: .-.-. Internet Access Link 274 Figure 1 276 Toward PSTN/Internet Inter-Networking May 1998 278 Where all nodes are on the same (broadcast) network, there is no need 279 for intervening routers; they can send and deliver packets to one 280 another directly. The Internet nodes are responsible for their own 281 communications requests, and act as peers in the communication 282 sessions that result. 284 This contrasts with the situation in the PSTN. There, the end systems 285 are configured as shown in Figure 2. The end systems tend to be 286 specific to a particular type of traffic, so that, for example, the 287 majority of terminals are dedicated to carrying speech traffic 288 (telephones) or to carrying facsimile data (fax machines). The 289 terminals all connect to Central Offices (COs) via access lines, and 290 these COs are interconnected into a network. 292 /--\ 293 ()/\()__ 294 /__\ \ ................................. 295 \ ! ! ! /--\ 296 __ \ [-!-] [-!-] ! ()/\() 297 \ \ \__[CO ]=========[CO ]==\\ ! ___/__\ 298 [Fax]________[---] [---] \\ [-!-] / __ 299 \\=======[CO ]____/ \ \ 300 [---]________[Fax] 301 Key: ___ Access Lines 302 === Trunk Links (inter-CO user data links) 303 ... Inter-CO signaling network links 304 CO Central Office (Telephone Exchange) 306 Figure 2 308 Communications between the terminals are all "circuit switched", so a 309 dedicated synchronous data path (or circuit) needs to be placed 310 between the end terminals for carrying all communications. Arranging 311 for such a circuit to be made or removed (cleared) is the 312 responsibility of the Central Offices in the network. A user makes a 313 request via his or her terminal, and this request is passed on to the 314 "local" Central Office. The relationship between the terminals and 315 the local Central Offices to which they are connected is strictly 316 Client/Server. 318 The COs are interconnected using two different types of connections. 319 One of these is called a trunk connection (shown as a double line in 320 the above figure) and is used to carry the data traffic generated by 321 the terminals. The other connection acts as part of a separate 322 network (and is shown as a dotted line in the above figure). This is 323 the signaling network, and is used by the Central Offices to request 324 a connection to be made between themselves and the destination of the 325 required circuit. This will be carried across the trunk link to the 326 "next" Central Office in the path. The path, once in place through 327 the PSTN, always takes the same route. This contrasts with the 328 Internet, where the underlying datagram nature of the infrastructure 329 means that data packets are carried over different routes, depending 331 Toward PSTN/Internet Inter-Networking May 1998 333 on the combined traffic flows through the network at the time. 335 The call set up process can be viewed as having two parts: one in 336 which a request for connection is made, and the other in which the 337 circuit is made across the PSTN and call data flows between the 338 communicating parties. This is shown in the next pair of figures (3a 339 and 3b). 341 /--\ 342 () () 343 --____ 344 /++\ \ 345 /----\ \ 346 A \ [-!-] 347 \->[CO ] 348 [---] 349 Time = 13:55 351 Figure 3a 353 Key: ___ Access Lines 354 === Trunk Links (inter-CO user data links) 355 ... Inter-CO signaling network links 356 CO Central Office (Telephone Exchange) 358 /--\ 359 () () 360 -- ................................. 361 / \<--- ^ ! ! /--\ 362 /----\ \ ! v ! () () 363 A' \ [-!-] [-!-] ! -- 364 \__[CO ]=========[CO ]==\\ v ->-/ \ 365 [---] [---] \\ [-!-] / /----\ 366 \\=======[CO ]____/ B' 367 Time = 14:00 [---] 369 Figure 3b 371 Figure 3 shows a particular kind of service that can be provided; 372 call booking. With this service, a request is sent for a connection 373 to be made between the A and B telephones at a specified time. The 374 telephone is then replaced (the request phase is terminated). At the 375 specified time, the CO will make a connection across the network in 376 the normal way, but will, first, ring the "local" or A' telephone to 377 inform the user that his or her call is now about to be made. 379 For more complex services, the requesting telephone is often 380 connected via its "local" CO to a Service Node (SN), where the user 381 can be played prompts and can specify the parameters of his or her 382 request in a more flexible manner. This is shown below, in Figures 384 Toward PSTN/Internet Inter-Networking May 1998 386 4a and 4b. For more details of the operation of the Service Node (and 387 other Intelligent Network units), see the Appendix. 389 When the SN is involved in the request and in the call setup process, 390 it appears, to the CO, to be another PSTN terminal. As such, the 391 initial request is routed to the Service Node, which, as an end 392 system, then makes two independent calls "out" to A' and B'. 394 /--\ [---] 395 () () [SN ] 396 --___ [|--] 397 /++\ \ | 398 /----\ \ | 399 \ | 400 A \ [|-!] 401 \->[CO ] 402 [---] 403 Time = 13:55 405 Figure 4a 407 Key: ___ Access Lines 408 === Trunk Links (inter-CO user data links) 409 ... Inter-CO signaling network links 410 CO Central Office (Telephone Exchange) 411 SN Service Node 413 /--\ [---] 414 () () [SN ] 415 -- [|--] /--\ 416 / \<-- | ............................... () () 417 /----\ \ | ^ ! ! -- 418 \ | / v v / \ 419 A' \ [|-!] [-!-] [-!-] ->-/----\ 420 \--[CO ] [CO ] [CO ] / 421 [---] [---] [---]___/ B' 422 Time = 14:00 424 Figure 4b 426 Note that in both cases as shown in Figures 3 and 4 a similar service 427 can be provided in which the B' telephone is replaced by an 428 Intelligent Peripheral (or an Special Resource Functional entity 429 within a Service Node), playing an announcement. This allows a "wake 430 up" call to be requested, with the Intelligent Peripheral or Service 431 Node Special Resource playing a suitable message to telephone A' at 432 the specified time. Again, for more details of the operation of the 433 Special Resources (and other Intelligent Network units), see the 434 Appendix. 436 Toward PSTN/Internet Inter-Networking May 1998 438 4.2 Pre-PINT Systems 440 Although the pre-PINT systems reported here (i.e., those developed by 441 AT&T, Lucent, Siemens and Nortel) vary in the details of their 442 operation, they exhibit similarities in the architecture. This 443 section highlights the common features. Specific descriptions of 444 these systems will follow. 446 All of the systems can be seen as being quite similar to that shown 447 in the following diagram. In each case, the service is separated into 448 two parts; one for the request and another for execution of the 449 service. Figure 5 summarizes the process. 451 _____ 452 __ _____/ \_____ 453 [__] / \ 454 [-++-]-.-.>.-. Internet .-.- 455 \_____ _______/ . 456 \___/ v 457 [----] . 458 [PINT]-.- 459 [----] 460 % 461 v 462 [---] 463 [SN ] 464 [|--] 466 Figure 5a 468 Key: CO Central Office (Telephone Exchange) 469 SN Service Node 470 PINT PSTN/Internet Gateway 471 .-.-. Internet Access Link 472 %%% Gateway/Service Node Link 473 ___ PSTN Access Lines 474 === PSTN Trunk Links (inter-CO user data links) 475 ... Inter-CO signaling network links 477 Toward PSTN/Internet Inter-Networking May 1998 479 _____ 480 __ _____/ \_____ 481 [__] / \ 482 [----]-.-.-.-. Internet .-.- 483 \_____ _______/ . 484 \___/ | 485 [----] . 486 [PINT]-.- 487 [-%--] 488 % 489 % 490 /--\ [-%-] 491 () () [SN ] 492 -- [|--] /--\ 493 / \<-- | .................... () () 494 /----\ \ | ^ ! ! -- 495 \ | / v v / \ 496 A' \ [|-!] [-!-] [-!-] ->-/----\ 497 \--[CO ]=======[CO ]======[CO ] / 498 [---] [---] [---]__/ B' 500 Figure 5b 502 Comparing Figure 4a with Figure 5a, the differences lie in the way 503 that the information specifying the request is delivered to the 504 Service Node. In the PSTN/IN method shown in the earlier diagram, the 505 user connects to the SN from the telephone labeled A, with the 506 connection being routed via the CO. In the latter case, the request 507 is delivered from an Internet node, via the PINT gateway, and thence 508 to the Service Node over a "private" link. The effect is identical, 509 in that the request for service is specified (although the actual 510 parameters used to specify the service required may differ somewhat). 512 The figures depicting the respective service execution phases 513 (Figures 4b and 5b) show that the operation, from the IN/PSTN 514 perspective, is again identical. The Service Node appears to initiate 515 two independent calls "out" to telephones A' and B'. 517 The alternative systems developed by AT&T and by Nortel allow another 518 option to be used in which the PINT Gateway does not have to connect 519 to the PSTN via a Service Node (or other Intelligent Network 520 component), but can instead connect directly to Central Offices that 521 support the actions requested by the gateway. In these alternatives, 522 the commands are couched at a "lower level", specifying the call 523 states required for the intended service connection rather than the 524 service identifier and the addresses involved (leaving the 525 Intelligent Network components to coordinate the details of the 526 service call on the gateway's behalf). In this way the vocabulary of 527 the commands is closer to that used to control Central Offices. The 528 difference really lies in the language used for the services 529 specification, and all systems can use the overall architecture 530 depicted in Figure 5; the only question remains whether the 531 Intelligent Network components are actually needed in these other 533 Toward PSTN/Internet Inter-Networking May 1998 535 approaches. 537 The following diagram (Figure 6) shows the interface architecture 538 involved in providing the kind of service mentioned above. 540 Internet __ __ 541 Server [__] _______ [__] 542 [W3S-]-. ___/ .-.-.-[W3C-] Internet 543 _________________|/.-.-.-.-. \ Terminal 544 / .. . \ 545 | Internet / . \ | 546 \___________ . . . / 547 \/___|____\_________/ 548 . . . 549 / | \ 550 (A) (B) (E) 551 . . . 552 _|_ _|_ _|_ 553 [SN ]<-(D)--[SMS]--(H)->[SCP] 554 [|-|] --- [-!-] 555 / \ ! 556 (C) (I) ...........(F)...!.(G). 557 / \ ! ! 558 [--|] [|-!] [-!-] 559 [CO ] [MSC] [SSP] 560 [---] [---] \|/ [---] 561 /--\ | |____| | /--\ 562 ()/\() | | ()/\() 563 /--\___| 1 |___/--\ 564 Fixed PSTN Terminal [] Fixed PSTN Terminal 565 Mobile Terminal 567 Key: W3S HTTP (Web) Server 568 W3C HTTP (Web) Client/Browser 569 CO Central Office (Telephone Exchange) 570 MSC Mobile Switching Center (Mobile Network Telephone Exchange) 571 SN Service Node 572 SSP Service Switching Point 573 SCP Service Control Point 574 SMS Service Management System 575 .-.-. Internet relationship 576 ___ PSTN Access relationship 577 ... PSTN "core" signaling relationship 579 Figure 6 581 The interfaces are: 583 A The interface over which Internet requests for service are delivered 584 to the Service Node 585 B The interface over which Service Management requests are sent 586 from the Internet to the Service Management System 588 Toward PSTN/Internet Inter-Networking May 1998 590 C The interface over which the Service Node sends call control requests 591 to a connected Central Office 592 D The interface over which the Service Management System manages the 593 Service Node 594 E The interface over which Internet requests for service are delivered 595 to the Service Control Point 596 F The interface over which the Service Control Point sends service call 597 control requests to the Mobile Switching Center 598 G The interface over which the Service Control Point sends service 599 control requests to the Service Switching Point 600 H The interface over which the Service Management System manages the 601 Service Control Point 602 I The interface over which the Service Node sends service call control 603 requests to the Mobile Switching Center 605 In practice, a number of the interfaces have very similar purposes to 606 one another. The means by which these purposes are achieved differ, 607 in that some of the interfaces (C and I) reflect access arrangements, 608 whilst others (F and G) imply a "core" signaling relationship. 609 However, it is possible to categorize them in terms of the "intent" 610 of messages sent across the interfaces. 612 For example, Interfaces A and E are similar; one of the main aims of 613 PINT work is to ensure that they are the same. Similarly, Interfaces 614 D and H imply similar actions and are likely to carry similar 615 messages. Interfaces C, F, G, and I are all used to request that a 616 call be initiated, albeit via access or core signaling relationships. 618 The interfaces can also be viewed in terms of the kind of components 619 that are involved and the bodies by which they are codified. 620 Interfaces A, B, and E are all going to be realized as Internet 621 Protocols. All of the others use existing protocols in the PSTN/IN. 622 Traditionally, these have been codified by different groups, and this 623 is likely to be the case in the PINT work. 625 The general arrangements for the different systems are shown below 626 (Figures 7, 8, 9, and 10). They differ in the details of their 627 configurations, but the main tasks they perform are very similar, and 628 so the overall operation is similar to the generic architecture shown 629 in Figures 5 and 6. 631 Toward PSTN/Internet Inter-Networking May 1998 633 Key for following diagrams: 634 Components: 636 W3C World Wide Web Client 637 W3S World Wide Web Server 638 WSA Web Server "Back End Program" Interface (CGI or Servlet interface) 639 Srvlt Servlet "back end" program/objects 640 FS Finger Server 641 SCTPC Simple Computer Telephony Protocol Client 642 SCTPS Simple Computer Telephony Protocol Server 643 CBC CallBroker Client 644 CBS CallBroker Server 645 SSTPC Service Support Transport Protocol Client 646 SSF Service Switching Function 647 SCF Service Control Function 648 SRF Special Resource Function 649 CO Central Office/ Public Telephone Exchange 650 SSP Service Switching Point 651 SCP Service Control Point 652 SR/I.IP Special Resource/ "Internet" Intelligent Peripheral 653 SMS Service Management System 654 INAPAd Intelligent Network Application Part Adaptor 655 PktFlt Packet Filter (Firewall) 656 SNMPAg Simple Network Management Protocol Agent 658 Protocols: 659 P0 HyperText Transfer Protocol 660 P1 HTTP Server <-> "Back End Program" internal protocol 661 P2 CallBroker Client <-> CallBroker Server protocol (AT&T system), 662 or SCTP Client <-> Server protocol (Nortel system) 663 P3 PINT User Agent <-> PINT Gateway protocol 664 P4 Intra-Intelligent Network protocol (e.g., INAP) 665 P5 Proprietary (INAP-based) Gateway-> I.IP protocol 666 P6 Finger protocol 667 P7 Digital Subscriber Signaling 1 protocol 668 P8 Simple Network Management Protocol 669 P9 SMS <-> Service Control Point/Service Node protocol 671 Toward PSTN/Internet Inter-Networking May 1998 673 _____ _______ _____ 674 |[W3C]|----(p0)-->| [W3S] |<--(p0)----|[W3C]| 675 |[---]| | [WSA] | |[FS.]| 676 |-----| | ! | |[-!-]| 677 | (p1) | |--\--| 678 | ! | ^ 679 | ! | (p6) 680 | ! | \ 681 | (p1) | \ 682 | ! | \ 683 |[Srvlt]| \ 684 |___!___| \ 685 ! \ 686 (p3) \ 687 Internet ! ! 688 .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.!.+.+.+.+.+.+.+. 689 PSTN/IN _______________!_________________ ____!_____ __________ 690 |I [PktFlt] I| |[PktFlt]| |[PktFlt]| 691 |N Gateway N| | ! | | ! | 692 |A ___________________________ A| | ! | | ! | 693 |P | | P| | ! | |[SNMPAg]| 694 -(p4)-- |A | <-(p4)-> [SCP] <-(p4)-> | A|-(p5)->|[SR/IIP]| | [SMS] | 695 \ |d | [-^-] | d| |[------]| | [-^-] | 696 \ |__| ! |__| |________| |___!____| 697 \ ! ! 698 [-v-] !-----------------(p9)---------------------! 699 [SSP] 700 [---] 701 ___| |______ 702 | | 703 | /--\ | /--\ 704 | ()/\() | ()/\() 705 |__/__\ |____/__\ 707 Figure 7: The Siemens Web Call Center 709 Toward PSTN/Internet Inter-Networking May 1998 711 _____ _______ 712 |[W3C]|----(p0)-->| [W3S] | 713 |[---]| | [WSA] | 714 |-----| | ! | 715 | (p1) | 716 | ! | 717 | ! | 718 | ! | 719 | (p1) | 720 | ! | 721 |[SSTPC]|-<-------------------------------------- 722 |___!___| ! 723 ! (p8) 724 (p3) ! 725 Internet ! v 726 .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+ 727 PSTN/IN _______________!__________________________________ ____!_____ 728 | [PktFlt] Service [PktFlt]| |[PktFlt]| 729 | ! Node | | ! | 730 | [SCF Adaptor] | | ! | 731 | ! | |[SNMPAg]| 732 |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] | 733 |[|--] [-^-] [---] | | [-^-] | 734 |_|_____________!________________________________| |___!____| 735 | ! ! 736 [-v-] (p7) !-----------------(p9)---------------------! 737 [CO.]____| 738 [---] 739 ___| |_______ 740 | | 741 | /--\ | /--\ 742 | ()/\() | ()/\() 743 |__/__\ |____/__\ 745 Figure 8: The Lucent System 747 Toward PSTN/Internet Inter-Networking May 1998 749 _____ ________ 750 |[W3C]|----(p0)-->| [W3S] | 751 |[---]| | [WSA] | 752 |-----| | ! | 753 | (p1) | 754 | ! | 755 |[WS/CBS]| 756 |[Adaptr]| 757 |___!____| 758 ^ 759 (p2) 760 _____ ___v____ 761 |[CBC]| | [CBS] | 762 |[---]|<---(p2)-->| [---] |-<------------------------------------- 763 |-----| |___!____| ! 764 ! (p8) 765 (p3) ! 766 Internet ! v 767 .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+ 768 PSTN/IN _______________!__________________________________ ____!_____ 769 | [PktFlt] Service [PktFlt]| |[PktFlt]| 770 | ! Node | | ! | 771 | [SCF Adaptor] | | ! | 772 | ! | |[SNMPAg]| 773 |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] | 774 |[|--] [-^-] [---] | | [-^-] | 775 |_|_____________!________________________________| |___!____| 776 | ! ! 777 [---] (p7) !-----------------(p9)---------------------! 778 [CO.]____| 779 [---] 780 ___| |_______ 781 | | 782 | /--\ | /--\ 783 | ()/\() | ()/\() 784 |__/__\ |____/__\ 786 Figure 9: The AT&T System 788 Toward PSTN/Internet Inter-Networking May 1998 790 _____ ________ 791 |[W3C]|----(p0)-->| [W3S] | 792 |[---]| | [WSA] | 793 |-----| | ! | 794 | (p1) | 795 | ! | 796 |[WS/ ]| 797 |[ SCTPS]| 798 |[Adaptr]| 799 |___!____| 800 ^ 801 (p2) 802 _______ ___v___ 803 |[SCTPC]| |[SCTPS]| 804 |[-----]| <-(p2)--> |[-----]|-<-------------------------------------- 805 |-------| |___!___| ! 806 ! (p8) 807 (p3) ! 808 Internet ! v 809 .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+. 810 PSTN/IN _______________!__________________________________ ____!_____ 811 | [PktFlt] Service [PktFlt]| |[PktFlt]| 812 | ! Node | | ! | 813 | [SCF Adaptor] | | ! | 814 | ! | |[SNMPAg]| 815 |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] | 816 |[|--] [-^-] [---] | | [-^-] | 817 |_|_____________!________________________________| |___!____| 818 | ! ! 819 [---] (p7) !-----------------(p9)---------------------! 820 [CO.]____| 821 [---] 822 ___| |_______ 823 | | 824 | /--\ | /--\ 825 | ()/\() | ()/\() 826 |__/__\ |____/__\ 828 Figure 10: The Nortel System 830 As these are independent systems developed by different groups, the 831 names of the components, unsurprisingly, don't match. Some features 832 are offered by one of the systems, while they aren't by others. 833 However, there are a number of common features. All of the systems 834 provide a Web-based interface (at least as an option), using "back 835 end" programs to construct protocols to pass onwards to the 836 Intelligent Network system. 838 Several Intelligent Network Functional Entities are combined into a 839 Service Node in the Lucent, AT&T , and Nortel systems, while in the 840 Siemens scheme they are separate units. However, this is not 841 particularly important for the provision of the services they offer. 843 Toward PSTN/Internet Inter-Networking May 1998 845 The main difference lies in whether or not the SCF is "aware" of the 846 Internet interface and has been modified to be "complicit" in 847 supporting these Internet requests. The Siemens approach was to re- 848 use an existing SCP, providing a gateway function to translate as 849 needed. The Lucent system used a "lighter weight" SCF adapter to 850 terminate the Internet protocols, as the SCF was modified to support 851 the Internet interface directly. 853 The AT&T CallBroker and Nortel SCTP Servers introduce an intermediate 854 protocol (labeled p2) that allows an alternative to the Web based 855 interface supported by the others. This protocol matches the 856 "CallBroker Client API", or the "SCTP Client API". These options 857 provide for a bi-directional protocol, with indications sent from the 858 Call Broker or SCTP Server to the Client as needed. This is not 859 easily possible using an HTTP-based scheme (and in the Siemens case, 860 a dedicated Finger client/server pair was used to emulate such an 861 interface) 863 The protocol between the Internet server and the Intelligent Network 864 (labeled p3 in the above diagrams) differs in each of the systems. 865 One of the main aims of future work will be to develop a common 866 protocol that will support the services offered, so that the p3 867 interface will allow different implementations to inter-operate. In 868 the Lucent, Siemens, and Nortel systems, this was an "internal" 869 protocol, as it was carried between entities within the Service Node 870 or Gateway. 872 Other contrasts between the systems lie in the support for Internet 873 access to Service Management, and access to the Internet by Special 874 Resources. Internet Management access was most developed in the 875 Lucent system, in which a Simple Network Management Protocol (SNMP) 876 agent was provided to allow inter-operation with the SMS controlling 877 the Service Node. In the Siemens scheme, the SMS had no direct 878 Internet access; any management actions were carried out within the 879 normal PSTN management activities. As for Internet access to special 880 resources, this was only required by the Siemens system as part of 881 its support for Call Center agent notification. Equivalent 882 functionality would be provided in the AT&T and Nortel systems as 883 mentioned above, and this would in turn be associated with event 884 notifications being sent as part of their (p3) Internet/IN protocol. 885 These differences reflect the different emphases in the products as 886 they were developed; again, future work will have to ensure that 887 common protocols can be used to support the chosen services fully. 889 5. IN-Based Solutions 891 5.1 The Lucent System 893 Figure 11 depicts the overall interconnection architecture of the 894 Lucent prototype in support of the four PINT services. The IN-based 895 architecture utilizes the Service Node and Service Management System 896 in addition to the Web server, which enables Web-based access to the 897 PINT services. This section summarizes the roles of these elements 899 Toward PSTN/Internet Inter-Networking May 1998 901 (complemented by a click-to-dial-back service scenario), outlines the 902 interfaces of Web Server-Service Node and Web Server-Service 903 Management System (i.e., the interfaces A & B), and addresses the 904 common security concerns. 906 5.1.1 Roles of the Web Server, Service Node, and Service Management 907 System 909 Web Server 911 The Web Server stores the profiles of content providers as well as 912 pre-registered users. The content provider profile contains 913 information such as content provider ID, telephone number, and fax 914 number. In addition, the profile may also include service logic that 915 specifies, for example, the telephone (or fax) number to be reached 916 based on time of the day, day of the week, or geographical location 917 of the user, and the conditions to accept the charge of the calls. 919 Similar to the content provider profile, the pre-registered user 920 profile contains information such as user name, password, telephone 921 number, and fax number. The last two pieces of information can also 922 be linked to time of the day and day of the week so the user can be 923 reached at the appropriate telephone (or fax) number accordingly. 925 Service Node 927 Situated in the PSTN, the SN, like the SCP, performs the service 928 control function [1, 2, 3]. It executes service logic and instructs 929 switches on how to complete a call. The SN also performs certain 930 switching functions (like bridging of calls) as well as a set of 931 specialized functions (like playing announcements, voice recognition 932 and text-to-speech conversion). 934 Service Management System 936 The SMS performs administration and management of service logic and 937 customer-related data on the SN. It is responsible for the 938 replication of content provider profiles and provision of these data 939 on the SN. These functions are non-real time. 941 Toward PSTN/Internet Inter-Networking May 1998 943 Web Users 944 ____________ 945 O -------------------------- | Internet |------------------------ 946 ------------ | 947 | 948 | 949 ---------------- -------------- --------------- 950 | Service Node | D | Service | B | Web Server | 951 | (SN) |------------| Management |------------------| | 952 | | |System (SMS)| | | 953 | | A -------------- | | 954 | |--------------------------------------------| | 955 ---------------- --------------- 956 | | 957 | I | C 958 | | 959 ----------- --------- 960 |Mobile | |Central| 961 |Switching| |Office | 962 | Center | --------- 963 ----------- | 964 | | 965 | | 966 O O 968 Mobile Wireline PSTN 969 Users Users 971 Figure 11: Overall Interconnection Architecture of the Lucent System 973 5.1.2 A Click-to-Dial-Back Service Scenario 975 A Web user, who has simultaneous access to the Web and telephone 976 services (this can be achieved, for example, by having an ISDN 977 connection), is browsing through a sales catalogue and deciding to 978 speak to a sales representative. 980 When the Web user clicks a button inviting a telephone call from the 981 sales office, the Web Server sends a message to the SN over the A 982 interface, thus crossing the Internet-to-PSTN boundary. By matching 983 the information received from the Web Server with the content 984 provider profile that had been previously loaded and activated by the 985 SMS over the D interface, the SN recognizes the signal. 987 At this point, the SN calls the Web user. The user answers the call, 988 hears an announcement, e.g., "Please wait, while we are connecting 989 you to the sale agent", and is waiting to be connected to the sale 990 agent. Then the SN invokes service logic as indicated in the profile. 991 The execution of this logic selects an appropriate sales agent to 992 call based on the time of the day. It is 8 P.M. in New York where 993 the Web user is located, and the New York sales office has closed. 994 The San Francisco office, however, is still open, and so the SN makes 996 Toward PSTN/Internet Inter-Networking May 1998 998 a call to an agent in that office. Finally, the SN bridges the two 999 calls and establishes a two-party call between the sales agent and 1000 the Web user. 1002 5.1.3 Web Server-Service Node Interface 1004 Lucent developed the Service Support Transfer Protocol (SSTP) for 1005 communications between the SN and Web Server. SSTP is of a 1006 request/response type running on top of a reliable transport layer, 1007 such as TCP. The Web Server sends a request to the SN to invoke a 1008 service and the SN responds with a message indicating either success 1009 or failure. Note that SSTP engages only the service control function 1010 [1, 2, 3] of the SN. 1012 5.1.3.1 Web Server to Service Node 1014 In this direction, three kinds of messages may be sent: the 1015 Transaction Initiator message, the Data Message, and the End of Data 1016 message. 1018 The latter two messages are needed if the service to be invoked 1019 involves data (such as the case in click-to-fax, click-to-fax-back 1020 and voice-access-to-content). This was so designed to handle the 1021 varying size of data and to ensure that the size of each stream is 1022 within the allowable size of the underlying transport packet data 1023 unit (imposed by some implementations of TCP/IP). 1025 a. Transaction Initiator 1027 This message provides all the necessary information but data for 1028 invoking a service. It includes the following information elements: 1030 + Transaction ID, which uniquely specifies a service request. The 1031 same transaction ID should be used for all the accompanying data- 1032 related messages, if the service request involves data. One way for 1033 generating unique transaction IDs is to concatenate the information: 1034 date, time, Web Server ID (uniquely assigned for each one connected 1035 to the SN), and transaction sequence number (a cyclic counter 1036 incremented for each service request). 1038 + Service ID, which specifies the service to be invoked. The service 1039 may be click-to-dial-back, click-to-fax, click-to-fax-back or voice- 1040 access-to-content. 1042 + Content Provider ID, which uniquely represents the content 1043 provider. This information is the key to accessing the content 1044 provider's service logic and data on the SN. 1046 + Content Provider Directory Number, which is the telephone or fax 1047 number of the content provider to be called through the PSTN. 1049 + User Directory Number, which is the telephone or fax number of the 1050 user requesting the service. 1052 Toward PSTN/Internet Inter-Networking May 1998 1054 + Billed Party, which specifies the party (either the user or content 1055 provider), to be billed. 1057 In addition, optional parameters may be sent from the Web Server to 1058 the SN. For example, a retry parameter may be sent to specify the 1059 number of times the SN will attempt to complete a service request 1060 upon failure before the transport connection times out. 1062 b. Data Message 1064 This message provides the (encapsulated) user data part of a service 1065 request. For example, in the case of click-to-fax-back such data are 1066 the content to be faxed to the user. Each message is composed of the 1067 transaction ID and a data segment. The transaction ID must be the 1068 same as that of the transaction initiator part first invoking the 1069 service. 1071 c. End of Data Message 1073 This message contains the transaction ID and the end of data 1074 delimiter. The transaction ID is the same as that of the relevant 1075 transaction initiator message. 1077 B. Service Node to Web Server 1079 The SN must respond to a service request from the Web Server. The 1080 response message consists of the information elements: 1082 transaction ID, service type, result, time, and error code. 1084 + Transaction ID, which is the same as that of the original service 1085 request. 1087 + Service Type, which is the same as that of the original service 1088 request. 1090 + Result, which is either success or failure. 1092 + Time, which indicates the time of the day completing the request. 1094 + Error Code, which gives the reason for failure. Possible reasons 1095 for failure are content provider telephone (or fax) busy, content 1096 provider telephone (or fax) no answer, user telephone busy, user 1097 refusal to complete, user no answer, nuisance control limit reached, 1098 and content provider telephone (or fax) not in the SN database. 1100 C. Usage Scenarios: Click-to-Fax and Click-to-Fax-Back 1102 For the click-to-fax and click-to-fax-back services, the Lucent 1103 system implemented only the case where the data to be sent as 1104 facsimile reside in the Web server. There are at least three messages 1105 that need to be sent from the Web server to the Service Node for 1106 these services. 1108 Toward PSTN/Internet Inter-Networking May 1998 1110 The first message is the Transaction Initiator that identifies the 1111 service type as well as a unique Transaction ID. It also includes the 1112 sender/receiver fax number. 1114 The next is one or more messages of the data to be faxed. Each 1115 message carries the same unique Transaction ID as the above. 1117 Last comes the end of message. It consists of the Transaction ID 1118 (again, the same as that of the messages preceding it) and the end of 1119 data delimiter. 1121 Upon receiving these messages, the Service Node, equipped with the 1122 special resource of a fax card, converts the data into the G3 format, 1123 calls the receiver fax, and sends back the result to the Web server 1124 immediately. Note that the receiver fax busy or no answer is 1125 interpreted as failure. Further, while the receiver fax answering the 1126 call is interpreted as success, it does not necessarily mean that the 1127 fax would go through successfully. 1129 5.1.4 Web Server-SMS Interface and SNMP MIB 1131 This interface is responsible for uploading the content provider 1132 profile from the Web Server to the SMS and for managing the 1133 information against any possible corruption. The SN verifies the 1134 Content Provider ID and the Content Provider Directory Number sent by 1135 the Web Server with the content provider profile pre-loaded from the 1136 SMS. 1138 The content provider profile was based on ASN.1 [4] structure and 1139 SNMP [5] was used to set/get the object identifiers in the SMS 1140 database. 1142 Following is an example of the simple MIB available on the SMS. 1144 inwebContProviderTable OBJECT-TYPE 1145 SYNTAX SEQUENCE OF InwebContProviderEntry 1146 MAX-ACCESS not-accessible 1147 STATUS current 1148 DESCRIPTION 1149 " A table containing Content Provider profiles " 1150 := { inweb 1} 1152 inwebContProviderEntry OBJECT-TYPE 1153 SYNTAX InwebContProviderEntry 1154 MAX-ACCESS not-accessible 1155 STATUS current 1156 DESCRIPTION 1157 " A conceptual row of the inweb. Each row 1158 contains profile of one Content Provider" 1159 INDEX { inwebSmsNumber } 1160 := { inwebContProviderTable 1 } 1162 InwebContProviderEntry := SEQUENCE { 1163 inwebSmsNumber Integer32, 1165 Toward PSTN/Internet Inter-Networking May 1998 1167 inwebContentProviderId Integer32, 1168 inwebContentProviderPhoneNumber Integer32, 1169 inwebContentProviderFaxNumber Integer32 1170 } 1172 inwebSmsNumber OBJECT-TYPE 1173 SYNTAX Integer32 1174 MAX-ACCESS read-only 1175 STATUS current 1176 DESCRIPTION 1177 " Serial number of the SMS - used for SNMP indexing " 1178 := { inwebContProviderEntry 1 } 1180 inwebContentProviderId OBJECT-TYPE 1181 SYNTAX Integer32 1182 MAX-ACCESS read-create 1183 STATUS current 1184 DESCRIPTION 1185 " A number that uniquely identifies each Content 1186 Provider " 1187 := { inwebContProviderEntry 2 } 1189 inwebContentProviderPhoneNumber OBJECT-TYPE 1190 SYNTAX Integer32 1191 MAX-ACCESS read-create 1192 STATUS current 1193 DESCRIPTION 1194 " Content Provider's Phone Number " 1195 := { inwebContProviderEntry 3 } 1197 inwebContentProviderFaxNumber OBJECT-TYPE 1198 SYNTAX Integer32 1199 MAX-ACCESS read-create 1200 STATUS current 1201 DESCRIPTION 1202 " Content Provider's Fax Number " 1203 := { inwebContProviderEntry 4 } 1205 5.1.5 Security Considerations 1207 The Lucent prototype addressed the security issues concerning the 1208 interface between the Web Server and the SN. Those concerning the 1209 interface between the Web Server and SMS, which was based in SNMP, 1210 were handled by the built-in security features of SNMP. 1212 + Secure Communication Links 1214 If the Network Operator (PSTN provider) is also the Web Service 1215 provider, the Web Server and SN/SMS will communicate over a corporate 1216 intranet. This network is almost always protected by the 1217 corporation's firewall and so can be deemed secure. This was the case 1218 handled by the Lucent prototype. 1220 Nevertheless, if different corporations serve as the Network Operator 1222 Toward PSTN/Internet Inter-Networking May 1998 1224 and the Web Service Provider, then it is likely that there may not 1225 exist a dedicated secure communication link between the Web Server 1226 and SN/SMS. This raises serious security considerations. One possible 1227 solution is to use Virtual Private Networks (VPN). VPN features 1228 support authentication of the calling and called parties and 1229 encryption of the messages sent over insecure links (such as those on 1230 the Internet). 1232 + Non-Repudiation 1234 All transactions were logged on both the Web Server and the Service 1235 Node to account for all operations in case of doubt or dispute. The 1236 log information on the SN may also be used to generate bills. 1238 + Malicious Requests of Users 1240 A user may make repeated requests to a content provider directory 1241 number maliciously. This scenario was handled by setting a Nuisance 1242 Control Limit (NCL) on either the SN or the Web Server or both. The 1243 NCL has two parameters: one defining the number of requests from a 1244 user and the other the period over which these requests takes place. 1246 A user may also attempt to request a call from a directory number 1247 other than that of a content provider. This scenario was handled by 1248 verifying the directory number (and the content provider ID) against 1249 the database on the SN containing all the content provider 1250 information. If the directory number (or the content provider ID) was 1251 not in the database, the request would be rejected. 1253 5.2 Siemens Web Call Center 1255 5.2.1 Service Description 1257 The Web Call Center is an Intelligent Network System that accepts 1258 requests from Internet nodes for services to be provided on the PSTN. 1259 As the name suggests, it was designed to support a cluster of 1260 services that, taken together, provide a subset of the features of a 1261 Call Center, with almost all user interactions provided via World 1262 Wide Web requests and responses. See the appendix for a background 1263 description of Call Center Features. 1265 From an Intelligent Network perspective, there are a number of 1266 services that, when combined, provide the Call Center features. The 1267 Call Center features as implemented supported the scenario in which a 1268 customer makes a request to be called back by an agent at a time of 1269 the customer's choosing to discuss an item of interest to him or her. 1270 The agent will be selected based on his or her availability and 1271 expertise in this topic; the agent will be told whom he or she is 1272 calling and the topic of interest, and then the agent will be 1273 connected to the customer. 1275 In addition, the individual services that were deployed to support 1276 this scenario provided support for management of the list of 1277 available agents as well. This involved allowing the agent to "log 1279 Toward PSTN/Internet Inter-Networking May 1998 1281 into" and "out of" the system and to indicate whether the agent was 1282 then ready to handle calls to the customer. The list of services, as 1283 seen from a user perspective, follows. 1285 The services support: 1287 i) Customer Request service - the customer explores a corporate Web 1288 site, selects a link that offers to request an agent to call the 1289 customer back and then is redirected to the Web Call Center server. 1290 This presents customer with a form asking for name, the telephone 1291 number at which he or she wishes to be called, and the time at which 1292 the call is to be made. Note will also be made of the page to which 1293 the customer was referred to when he or she was redirected. Once the 1294 form has been returned, the customer receives an acknowledgment page 1295 listing the parameters he or she has entered. 1297 ii) Agent Registration/Logon - An agent requests a "login" page on 1298 the Web Call Center server. The service checks whether it has a 1299 record of an agent present at the Internet node from which th call is 1300 made. If not, then the caller will be sent a form allowing him or her 1301 to enter the service identity, the company's agent identifier and 1302 password. On return, the service identity and company agent 1303 identifier will be checked against a list of known identities. If 1304 found, the password will be checked, and if this matches the record 1305 held by the service then a new session record is made of this 1306 identity and the Internet node from which the call has been made. 1308 NB: This is very similar to the Universal Personal Telecommunications 1309 (UPT) service feature "register for incoming calls". It implies that 1310 the identified person has exclusive use of the Internet node from 1311 that point onwards, so messages for them can be directed there. 1313 iii) Agent Ready - an agent who has already logged on can indicate 1314 that he or she is ready by requesting an appropriate "ready" page on 1315 the Web Call Center Server. The service will match the agent by the 1316 Internet node Identifier and Agent Identity passed along with the Web 1317 request against its list of "active" agents. It will mark them as 1318 being ready to handle calls in its list of available agents (with 1319 their pre-defined skill set). 1321 iv) Agent Not Ready - an agent can request an appropriate "ready" 1322 page on the Web Call Center Server to indicate that he or she is 1323 temporarily not ready to handle calls. 1325 v) Agent Logoff - an agent can request an appropriate "Logout" page 1326 on the Web Call Center Server to indicate that he or she is no longer 1327 associated with a particular Internet node. The service will match 1328 the agent by the Internet Node Identifier and Agent Identity passed 1329 along with the Web request against its list of "active" agents. Once 1330 found, the session record for that agent is removed and the caller is 1331 notified of this with an acknowledgment page. 1333 NB: This is very similar to the UPT "unregister" service feature. 1335 Toward PSTN/Internet Inter-Networking May 1998 1337 vi) Call Center Agent Selection and Notification - When the time 1338 that the customer selected has arrived and an available agent with 1339 the right skills has been selected from the appropriate list, this 1340 service will send a notification to the Internet node associated with 1341 that agent. A dedicated server is assumed to be running on the 1342 agent's machine that, on receiving the notification, triggers the 1343 agent's browser into requesting a "Agent Call In" page from the Web 1344 Call Center Server. Once the agent's machine has made this request, 1345 he or she will be told that there is a customer to call. 1347 NB: This is similar to a "Message Waiting" or "Wake Up Call" service. 1349 Note: As implemented, the agent is led automatically into the 1350 following service (the returned Web page includes an automatic reload 1351 command). 1353 vii) Agent Instruction - a selected agent makes a request of the 1354 "Customer Processing" page on the Web Call Center Server. The 1355 Internet node Identifier and Agent Identity the agent uses will be 1356 matched against a list of agents expected to handle calls, and the 1357 instructions for the calls will be returned to the agent. 1359 NB: This is similar to a "Voice Mail Replay" message service, but in 1360 this case the message is automatically generated; there is no 1361 associated voice mail record feature accessible. 1363 Note: As implemented, the instructions page will include a number of 1364 buttons, allowing the agent to view the page the customer was looking 1365 at when he or she made the request, and to trigger the customer 1366 callback (as described next). 1368 ix) Agent/Customer Telephony Callback - the agent will make a 1369 request of a "dial-back" page on the Web Call Center Server. The 1370 Internet node Identifier and Agent Identity he or she uses will be 1371 matched against a list of agents expected to handle calls, and, when 1372 the appropriate records have been found, the service will make the 1373 telephone call through to the customer and then connect the agent to 1374 this telephone call (using the telephone number registered in the 1375 respective Call Center service record). 1377 5.2.2 Implementation 1379 5.2.2.1 Introduction 1381 The Siemens Web Call Center used an existing IN system and service 1382 logic that supported Call Center features. The scenario it supports 1383 is very similar to the Siemens IN-based Call Center on which it was 1384 based; one of the goals was to minimize changes to the service 1385 offered. It is also virtually identical to the service "Internet 1386 Requested Telephony Dial-back" provided by the Lucent system. 1388 As provided via the Internet, the services involved are mostly the 1389 same as those provided via the PSTN and IN alone. The main 1390 differences lie in the use of the World Wide Web as an interface to 1392 Toward PSTN/Internet Inter-Networking May 1998 1394 the services rather than a telephone, SSP, and Intelligent 1395 Peripheral. Also, the feature by which a telephone call is made 1396 between the agent and the customer is implemented within the IN 1397 system in a different way; this is the only element in which the PSTN 1398 is involved. 1400 5.2.2.2 Web Call Center Configuration 1402 The general arrangement for the Web Call Center system is shown in 1403 Figure 7. The components that were added to an existing IN system to 1404 deal with the Internet interface are described next. 1406 In addition to the SCP, SSP and SMS that were part of the original 1407 IN-based system, another unit was included to send notification 1408 messages to agents; in the IN system the agents were sent "wake up" 1409 telephone calls when they were required to handle their next 1410 customers' call back. This unit is called the "Internet Intelligent 1411 Peripheral", and its use is described later under "Non-World Wide Web 1412 Interactions". 1414 As there was a need to re-use as many of the existing IN components 1415 unchanged, a Gateway unit to deal with the interface between the 1416 Internet and the SCP was provided. This injected INAP (Intelligent 1417 Network Application Protocol) messages into the SCP, making it think 1418 that it had received an Initial DP trigger from an SSP. It also 1419 intercepted the "Connect To Resource" and "Prompt and Collect" INAP 1420 messages sent from the SCP, acting on these to return the parameters 1421 generated by the Internet users when they filled in the forms that 1422 triggered the service transaction. It also translated the "Play 1423 Announcement" message sent to the Intelligent Peripheral into a form 1424 that it could use. Finally, it passed on the INAP message used by 1425 the SCP to trigger SSP into making the telephone call back. 1427 5.2.2.3 User Interaction 1429 In the IN/PSTN-based system, the services have contact with the 1430 customers and agents via their telephones, SSPs, and Intelligent 1431 Peripherals programmed to play announcements to them and to capture 1432 their responses. These responses are indicated by DTMF tones sent by 1433 pressing keys on the telephones. 1435 In this case, almost all interactions are provided via World Wide Web 1436 requests and responses. The sequence of announcements and responses 1437 for each service are "collapsed" into individual form filling 1438 transactions, and the requests are not limited to digits (or "star" 1439 and "hash"). The implications of the use of forms on service 1440 operation are covered in more detail later (under HTTP/IN Service 1441 mapping). 1443 5.2.2.4 Service/Caller Identifiers 1445 When provided via the IN/PSTN-based system, the services are passed 1446 the Calling Line Identity (CLI) of the caller and the number the 1447 caller dials (the DN). The CLI value is used extensively to identify 1449 Toward PSTN/Internet Inter-Networking May 1998 1451 the caller and (in the case of the agent) to index into service data 1452 tables to decide what to do next. While an equivalent value to the 1453 DN is passed to the Web-based transactions as the requested Universal 1454 Resource Locator (URL), the CLI cannot be given reliably. The nearest 1455 equivalent caller identifier is the IP Address of the customer or 1456 agent's machine. However, the use of HTTP proxies means that this 1457 "original" Internet node Address may not be available; if a proxy is 1458 used then its IP Address will be associated with the request. 1460 In providing these Call Center features the customer only has one 1461 Web-based transaction; that of providing the initial request for a 1462 PSTN telephone callback. To do so he or she will have to fill in a 1463 form so as to specify not only the time to be called back, but also 1464 the telephone number to be reached. These values can be used if 1465 needed to identify the customer, and so the problem of originating 1466 Internet Node ambiguity is not relevant. 1468 With the agents, however, there are sequences of coupled 1469 transactions, and the particular sequence must be identified. There 1470 will be a number of such transactions being carried out at once, and 1471 there needs to be some identifier to show which agent is being 1472 handled in each case. 1474 Such an identifier is not part of a sequence of basic Web 1475 transactions. In a Web transaction, the HTTP Client/Web Browser makes 1476 a request, and the HTTP Server will respond to this, normally 1477 including some content in its reply message that will be processed by 1478 the browser, after which it closes the TCP connection. That's the end 1479 of the transaction; the HTTP client and server cannot normally 1480 maintain state information beyond this point. Any sequence is reduced 1481 to a set of unrelated transactions. 1483 A result of this simple pattern is that any state information 1484 reflecting longer or more complex interactions must be stored (at 1485 least partially) in the client system. One approach is the use of 1486 cookies [6]. These can be set by HTTP servers as part of their 1487 response to a request, and will be sent back with all subsequent 1488 requests for appropriate URLs as extra HTTP headers. These cookies 1489 allow the HTTP server to identify the client in the following 1490 requests, so that it can continue an extended session with the 1491 client. 1493 Cookies are used in providing the Internet Call Center. Persistent 1494 cookies are installed into the Web Browser on machines that are to be 1495 used by call center agents as a service management (pre-service) 1496 task. The cookie value is unique to the machine and is used to index 1497 into a list of machine IP addresses that is stored as part of the 1498 service data. 1500 Also, a session cookie is stored onto the agent's machine when the 1501 agent registers, and is cleared when he or she de-registers. This is 1502 used to identify the agent and so the IP address of the node with 1503 which the agent is associated (and from which the agent's subsequent 1504 requests should originate). The services that interact with Call 1506 Toward PSTN/Internet Inter-Networking May 1998 1508 Center agents use the agent session cookie value as an identifier; in 1509 principle this is unnecessary but it does simplify the session data 1510 lookup procedure. The rest of the services use the persistent machine 1511 identifier in place of the CLI, indexing into their service data 1512 using it. Both cookies are sent with each agent request; if they are 1513 not present, then the request is redirected to other services (for 1514 example to the agent Logon service). 1516 5.2.2.5 Mapping from HTTP Transactions to IN-Based Service Features 1518 All of the client-initiated services require user interaction. With 1519 the IN/PSTN-based system, the majority of the services are typified 1520 by the callers being connected to an announcement unit that plays 1521 them a list of choices and captures their selection. The caller can 1522 pre-dial the digits needed; in this case the prompts are not needed 1523 and are not made. 1525 The pattern of operation is somewhat different in the Internet case, 1526 as the initial HTTP request returns a response, after which the Web 1527 transaction has ended. Where that initial response returns a form to 1528 be filled in by the caller, subsequently submitting the form 1529 initiates a new HTTP transaction. This is all part of one instance 1530 of service, however. The service consists of two request/response 1531 pairs in tandem. 1533 Although it is possible to design a service to handle this pair of 1534 Web transactions as a single unit, it may be better to reconfigure 1535 it. The design of a service that deals with two Web exchanges as a 1536 single extended transaction is quite complex. It must maintain state 1537 across the pair of Web exchanges, and it has to handle a number of 1538 failure cases including dealing with time-outs and "out of time" 1539 submission of forms. The alternative is to split the service into two 1540 sub-features. The first of these reflects the initial request and 1541 delivery of the form by return, with the second one dealing with 1542 processing of the submitted form and returning any confirmation by 1543 reply. 1545 The services offered don't all require form-filling, and so can be 1546 treated as a single IN feature. There are two cases where forms are 1547 required. The first of these is the Customer Request service, while 1548 the other one is the "Agent Registration" service. In both cases the 1549 initial Web transaction (by which the form is requested and returned 1550 to the client) need not involve specific service logic processing; 1551 the initial delivery of the form to a customer or agent can be 1552 handled by a "normal" Web Server. In both cases the service logic is 1553 only triggered when the form is submitted; this means that, again, 1554 each of the services can be treated as a single IN feature. 1556 The IN service logic that deals with these requests has a general 1557 pattern of action. An HTTP request is received, and this triggers the 1558 IN service logic into action. The service logic "sees" this as an 1559 Initial DP message and starts its processing as if it had been sent 1560 from an SSF. The SCF uses what appears to it to be an Intelligent 1561 Peripheral to collect the parameters of the request, and then to send 1563 Toward PSTN/Internet Inter-Networking May 1998 1565 back final announcements to the requesting entity. 1567 The main difference, from the perspective of the IN service logic 1568 running on the SCF, is that the service does not need to instruct the 1569 SSF to make a temporary connection to the Intelligent Peripheral. It 1570 is as if this connection had already been made. Similarly, there is 1571 no need to close the service transaction by sending an explicit 1572 "Continue Execution" message to the SSF. 1574 The sequence of "prompt/collect" instructions used to collect service 1575 parameters from a caller in an IN service maps quite well to a 1576 sequence of requests to extract a data value from the HTTP request, 1577 based on a tag. This is a fairly standard feature of Web Server CGI 1578 or Servlet processing. Using this mapping minimizes the changes to 1579 the service design, in that the service logic "sees" an Intelligent 1580 Peripheral to which it sends normal "Request Report Prompt & Collect" 1581 messages, and from which it receives data values in response. 1583 All services have to fit in with the underlying HTTP interaction 1584 pattern, and so will be expected to send a final "Announce" 1585 instruction to the Intelligent Peripheral at the end of the service; 1586 this is done in many IN services anyway and in all of the service 1587 features described here. These announcements form the content 1588 returned to the Web Client. 1590 5.2.2.6 Non-World Wide Web Interactions 1592 There are two exceptions to the sole use of the World Wide Web for 1593 interaction. The first one occurs in the "Message Waiting"/"Wake Up 1594 Call" service by which the selected agent is informed of a callback 1595 request. World Wide Web transactions are very simple; the client 1596 browser makes a request for content associated with a particular HTTP 1597 URL, and the server sends a response, marking the end of the 1598 transaction. The server cannot make a spontaneous association with a 1599 client; it must be initiated by the client request. 1601 While it would be possible for the server to defer closing an earlier 1602 transaction (by not sending back all of the content specified and 1603 leaving the TCP connection open) it was decided that an alternative 1604 scheme would be more convenient. The "wake up call" was arranged by 1605 an "Internet Intelligent Peripheral" sending a request to a daemon 1606 process running on the selected agent's machine, using the Finger 1607 protocol [7]. The daemon sent back a standard response, but in 1608 addition the Web Browser on the agent's machine was triggered into 1609 making a further HTTP request of the server. In this way the "Agent 1610 Instruction" transaction is started automatically, while still 1611 allowing it to use a normal HTTP request/response pattern. 1613 The second exception occurs in the final "Agent/Customer Telephony 1614 Callback" service. While this transaction is initiated by the agent 1615 selecting a link on the "call instructions page" returned to them, 1616 and includes a "confirmation" page being sent back to them in an HTTP 1617 response, the purpose of this service is to make a telephone 1618 connection via the PSTN between the agent's telephone and the 1620 Toward PSTN/Internet Inter-Networking May 1998 1622 customer's telephone. It is the only service element that involves 1623 the PSTN directly. From an IN/PSTN perspective, the resulting 1624 telephone connection is different from that provided in the scheme 1625 using the IN and PSTN alone. In this case, a PSTN call is made out to 1626 the agent's telephone, another call is made out to the customer's 1627 telephone, and these calls are bridged. This differs from the earlier 1628 scheme, in which the agent originated a call to the voice mail replay 1629 system, and this call was redirected to a new destination (the 1630 customer's telephone). As this feature differs in purpose from the 1631 other services, and it requires a different implementation within the 1632 IN and PSTN system, it was organized as a separate service in this 1633 case. 1635 5.2.2.7 Security Considerations 1637 In the case of this system, assumptions were made that the interface 1638 presented to requesting agents and customers was provided via a fire 1639 wall to deal with most attacks on the IN components. The interface 1640 appeared as a Web Server, and there was no direct access to the HTTP 1641 documents served, nor to the servlets providing the service logic. 1643 The Callback service was deemed to have simpler security requirements 1644 than other IN services as it was akin to a free phone "1-800" service 1645 access number; the agents work for the service subscriber and are not 1646 charged directly. Similarly, the requesting customer is not charged 1647 for his or her request, nor for the resulting call back. Service 1648 subscribers would be willing to pay the costs of telephone calls 1649 generated as a result of this cluster of services, and the costs of 1650 running the agent services could be charged directly to them. As such 1651 the authorization for service is defined by the contract between the 1652 service subscriber and the service provider. 1654 Authentication of agents was seen as a problem. As an interim 1655 measure, cookies were used, but this scheme delivers the cookie data 1656 as a plain text item (a header of the Web request). Secure Socket 1657 Layer connections were required for communication with the agent 1658 services, and this had an impact on the performance of the IN system. 1660 5.2.3 Derived Requirements/Lessons 1662 Security is seen as a major issue. A firewall was used to control 1663 access to the IN Components. Similarly, SSL was used for 1664 communication with the Agents, so as to protect the cookie values 1665 that they were sending with their requests. 1667 For other services, it is likely that the entity from which requests 1668 appear to originate will be charged for the service to be rendered. 1669 This has implications in terms of authentication and authorization of 1670 service provision at the time of the request. It is necessary for the 1671 service to be authorized in such a way that non-repudiation is 1672 ensured; this is likely to mean that a certificate of identity be 1673 provided from the person making the request, and that this can be 1674 tied in with a financial account that that person has with the 1675 service provider. The certificate can then be stored as part of the 1677 Toward PSTN/Internet Inter-Networking May 1998 1679 billing record. While the process of electronic commerce is outside 1680 of the scope of this work, the mechanism by which a request for 1681 confirmation of identity is passed out to the requesting user and is 1682 delivered back to the service logic must be considered. 1684 When changing from a "pure" IN/PSTN system to one supporting requests 1685 via the Internet, the differences in the way that clients interacted 1686 with the services meant that the service logic had to be redesigned. 1687 It was realized that maintaining the state of a service during its 1688 processing was going to be a problem; this problem was sidestepped by 1689 re-engineering the services as form processors, allowing them to deal 1690 with fully specified requests as a single (Web) transaction. In 1691 addition, a "normal" Web Server was used to deliver the forms to the 1692 users. This is a change from the IN system, where the equivalent of 1693 the form (the prompts) were sent in sequence as part of the same 1694 service process. 1696 The Call Center features provided suited this change. However, this 1697 may not be the case for other IN services. It is quite common for 1698 services to be designed such that the user is prompted for a 1699 response, and the service continues dependent on this response. The 1700 Web form presents all of the options at once, so this kind of variant 1701 prompt/collect sequence is not possible. From this, it is difficult 1702 to see how an IN service could be reused without some degree of 1703 modification. 1705 An intermediate "gateway" system was provided to "cocoon" the service 1706 logic as far as possible from the details of the components with 1707 which it was working. Where needed, this unit translated calls from 1708 the service logic into commands that operated with the Internet (and 1709 the Web Server that acted as the interface). Our experience was that 1710 an SCP could be "spoofed" into thinking that it was operating with 1711 other IN components in the normal way. Within the limits of the 1712 service used, this proved simpler than was originally expected. 1714 Selecting this simple approach still allows a considerable range of 1715 services to be provided while maintaining any investment in existing 1716 IN systems. Modification of existing IN service logic was also 1717 easier than feared. All of the services examined provided 1718 announcements at the end of the service transaction, and this could 1719 be used to trigger a Web response to be sent back to the requesting 1720 Internet user. The changes to the Call Center service logic turned 1721 out to be minor; it took as long to analyze the service and see how 1722 it could be arranged as a sequence of "form processing" transactions 1723 as it did to make the changes to the service logic. 1725 In the Siemens Web Call Center, the "Internet Intelligent Peripheral" 1726 with which the service logic communicated was running as a separate 1727 program on the same node. Where more complex behavior is required of 1728 it (such as conversion of text to speech data and interface with the 1729 PSTN) then it would almost certainly be on a separate node. If data 1730 is transferred from the Internet in such a scheme, any intermediate 1731 gateway would be involved in relaying the data to this node. 1733 Toward PSTN/Internet Inter-Networking May 1998 1735 6. Alternative Solutions 1737 6.1 The AT&T System 1739 AT&T developed a framework for controlling voice and voice-band data 1740 (e.g., fax) and for providing PINT services. Key to the framework is 1741 CallBroker, a logical entity that acts on behalf of a user to set up 1742 sessions and make requests for PSTN resources. The sessions typically 1743 include initiation of calls between two or more end points specified 1744 by the user. In addition to its interactions with the PSTN for call 1745 setup, the CallBroker is responsible for other functions, when 1746 necessary, such as authentication and usage recording. 1748 This section briefly discusses the protocol at the two interfaces 1749 that need to be defined and the corresponding APIs to provide the 1750 above services. The two interfaces are (1) the one between the 1751 CallBroker (or Web Server) and the Service Control Function in the 1752 Service Node in the PSTN and (2) the one between the IP client and 1753 the CallBroker. The latter interface, in particular, will enable 1754 service providers to extend the architecture defined here to serve as 1755 a platform for other advanced/value-added services (to be identified 1756 later). In addition, the view taken here is that the IP client is 1757 more general, and implements a protocol for communication with the 1758 CallBroker that allows full two-way communications. For example, this 1759 is required for the cases where a called party hangs up and an 1760 indication may be necessary to be given to the IP Client about this 1761 status/progress. This is also necessary when conferencing to give an 1762 indication/status of various parties joining the call. 1764 6.1.1 High Level Architecture 1766 A high level architecture depicting various logical entities and the 1767 Interfaces among these logical Entities and the IP Client is shown in 1768 Figure 12. 1770 ________________ 1771 / 1772 1 _____ / 2 _____ 1773 /|________________| |________| | PSTN 1774 |____| \ |____| 1775 Call \ / SCF\ 1776 Broker \ / SN \ 1777 \_____________ 1778 / \ 1779 / \ 1780 / \ 1781 __ __ 1782 /\ /\ 1784 Calling Participant 1785 Party (Called Party) 1787 Figure 12: The CallBroker Architecture 1789 Toward PSTN/Internet Inter-Networking May 1998 1791 The CallBroker, in addition to the initiation and control of calls on 1792 behalf of the user, performs additional functions. These functions 1793 include authenticating the IP Client, usage recording, and management 1794 of the session for the IP Client for the telephony call. The notion 1795 of the session requires that a client state machine be maintained in 1796 the CallBroker. This also helps in notifying the IP Client about the 1797 status/progress of the requests generated from the IP Client. 1799 From the perspective of the IP Client, the logical entities needed 1800 for the above functions are within the CallBroker and are as shown in 1801 Figure 13 below. These correspond to the functions already 1802 discussed: Usage Recording Function, Session Management Function, 1803 Voice Bridge, and the Authentication Function. The fact that some of 1804 these functions may be physically separate from the CallBroker (such 1805 as the Voice Bridge being in the PSTN) is not inconsistent with the 1806 general view adopted here. Thus, the CallBroker Model mediates 1807 requests for network services and enables us to define various value 1808 added services in the future. 1810 llllllllllllllll 1811 l l 1812 l Call Broker l Authentication 1813 l Server l Function 1814 l ______ l Interface 2a ______ 1815 l | |x x xlx x x x x x x x x | | 1816 l |______|x l |____| 1817 l x x l 1818 l x xl Interface 2b 1819 lSession State lx 1820 l Mnmgt. x l x Usage Recording 1821 l Function l x Function 1822 l _______ x l x ______ 1823 l | | l x x x | | 1824 l |_____| xl |____| 1825 llllllllllllllll 1826 x 1827 x Interface 2c 1828 x 1829 _______ 1830 | | 1831 |_____| 1833 Bridge 1835 Figure 13: Functional Entities in the Call Broker 1837 Various interfaces (i.e., 2a, 2b, 2c in Figure 13) between different 1838 functional entities in the CallBroker may also be standardized. The 1839 Session State Management Function may be physically realized as part 1840 of the CallBroker Server. 1842 Toward PSTN/Internet Inter-Networking May 1998 1844 6.1.2 IP Client to CallBroker Interface 1846 Communication on the IP Client to CallBroker Interface (Interface 1 1847 in Figure 12) is a simple ASCII based protocol running directly on 1848 TCP. The messages on this interface are primarily requests from the 1849 client to the CallBroker, responses from the CallBroker to the IP 1850 client responding to the requests and unsolicited events from the 1851 CallBroker to the IP client. Since the communication is not strictly 1852 transaction oriented, traditional encapsulation protocols like HTTP 1853 cannot be used. There has been some ongoing work attempting to use 1854 multiple concurrent HTTP POST requests to support event delivery but, 1855 without too much difficulty, the ASCII protocol specified here can 1856 easily be mapped to the POST payload of the HTTP protocol. 1858 6.1.3 Protocol 1860 Basic Format 1862 The basic format of the protocol is as follows: 1864 [header]< 1865 < 1866 [body]< 1867 < 1868 < 1870 The header and body of the protocol are separated by 2 line feed 1871 characters. The format of the header and the body is described 1872 below. Line feed characters in the header or body will be escaped 1873 using simple URL encoding. 1875 Header 1877 [session-id | 0]< 1878 [message-id]< 1879 [version-info]< 1881 All CallBroker transactions are identified by sessions. A session 1882 does not necessarily correspond one-to-one to a TCP session. If the 1883 IP client is attempting to initiate a new session with the CallBroker 1884 the session-id field is populated with '0' to indicate session 1885 creation request. Every session request needs to be accompanied by 1886 sufficient information regarding authentication for the CallBroker to 1887 create the session. 1889 Message-id represents the operation of the message. 1891 Version-info contains optional version information of the protocol. 1892 This is to aid possible version mismatch detection and graceful error 1893 recovery. 1895 Body 1897 The body of the protocol messages consists of name value pairs. These 1899 Toward PSTN/Internet Inter-Networking May 1998 1901 name-value pairs are interpreted with reference to the message-id 1902 which signifies the operation to be performed by the CallBroker. 1904 6.1.4 APIs Exposed to the IP Client 1906 The APIs of the CallBroker exposed to the IP client are distinct and 1907 different from the APIs that the CallBroker uses from the different 1908 supporting subsystems including the authentication subsystem and the 1909 usage recording subsystem. The IP client APIs enable clients to 1910 effectively control voice conferencing. 1912 6.1.5 Voice-Bridge Control API 1914 The Voice Bridge Control API is used by CallBroker applications to 1915 access voice bridging functionality. The API distinguishes between 1916 sessions and calls. Calls represent actual voice calls placed from/to 1917 the voice bridge. These calls can be grouped together in sessions. 1918 All the calls that belong to a session are bridged. Calls have a 1919 significance outside the scope of sessions. Every call can be 1920 associated with multiple sessions with different weights at the same 1921 time. The advantage of this approach is the ability to support 1922 concepts like whispering in a conference call. Calls can also be 1923 dropped from a conference session and bridged together in a new 1924 session to give the notion of a sub-conference. These calls can later 1925 be re-added to the main conference session. 1927 6.2 Simple Computer Telephony Protocol 1929 6.2.1 Overview 1931 The Simple Computer Telephony Protocol (SCTP) is a third party call 1932 control protocol and as such does not comply with the PINT charter. 1933 SCTP is described in this section to show how PINT services could be 1934 implemented using SCTP, and where SCTP fits into the PINT 1935 architecture. 1937 In addition to third party call control, SCTP also provides 1938 subscriber (i.e., user) feature management (e.g., allows a user to 1939 set do not disturb, call forwarding parameters), and subscriber 1940 monitoring of terminal, line and address status. SCTP is strictly 1941 client/server-based. It has no provisions for peer to peer 1942 communications. SCTP runs as a TCP application protocol. It is 1943 ASCII-based and uses sockets. The SCTP Server is usually connected to 1944 a switch via a CTI (Computer-Telephony Integration) connection. 1945 Because of this, feature interactions are limited to those within the 1946 context of a single call, and not between PSTN services. The SCTP 1947 Server within a PINT Gateway could also be connected to an SN, or an 1948 SCP. See figures below. SCTP does NOT carry media. 1950 Toward PSTN/Internet Inter-Networking May 1998 1952 6.2.2 How SCTP Fits in with the Reference PINT Services 1954 SCTP Client as Part of a Web Server 1956 +------+ +--------+ +--------+ +------+ 1957 | | | | SCTP | | | | 1958 | |----| |-------| |----| | 1959 | | | | | | | | 1960 +------+ +--------+ +--------+ +------+ 1961 User's PC Web Server/ PINT Gateway SN/SCP/Switch 1962 CGI 1964 Figure 14: SCTP Client as Part of a Web Server 1966 In this architecture, the SCTP Client is embedded in the Web Server. 1967 It is there for the specific purpose of initiating calls to the PSTN 1968 based on user requests. The SCTP Server is within the PINT Gateway. 1969 We go through the classic PINT examples: 1971 Click-to-dial-back: The SCTP Client issues an SCTP MakeCall to the 1972 SCTP Server with the calling number supplied by Web page, and called 1973 number supplied by the user. 1975 Click-to-fax-back: SCTP Client issues an SCTP MakeCall to the SCTP 1976 Server with called number set to user's fax machine, and calling 1977 number set to Web Server's fax machine, and treatment set to the URI 1978 for the file to be faxed. The SCTP Server takes the file and feeds 1979 it into the call just as a fax machine would. 1981 Click-to-fax: SCTP Client issues an SCTP MakeCall with calling number 1982 set to user's fax machine, and called number set to Web Server's fax 1983 machine. How the file is supplied to the user's fax machine is 1984 outside the scope of SCTP. 1986 Voice-access-to-content: SCTP Client issues an SCTP MakeCall with 1987 called number set to user's telephone number, and calling number set 1988 to Web Server and treatment set to a URI for the file of the 1989 particular Web page to be read to the called number. The SCTP Server 1990 takes care of the file to voice conversion and this is fed into the 1991 call as if it were voice. 1993 In all of the above cases, the SCTP Client can generate a variety of 1994 different Web pages to send to the Web Server via CGI (Common Gateway 1995 Interface). The content of these pages is based on the call 1996 completion status of the CallMake SCTP action. 1998 Toward PSTN/Internet Inter-Networking May 1998 2000 SCTP Client Running on the User's PC 2002 +------+ 2003 HTML | | INTERNET 2004 +-----+ /--------------| | 2005 | |---/ +------+ 2006 | | Web Server 2007 | |---\ 2008 +-----+ \ 2009 User's PC \ SCTP +------+ +------+ 2010 \------------| |-------| | PSTN 2011 | | | | 2012 +------+ +------+ 2013 PINT Gateway SN/SCP/Switch 2015 Figure 15: SCTP Client Running on the User's PC 2017 In this architecture, the user has an SCTP Client co-located with it. 2018 If the user is using the telephone line for connection to a Web 2019 Server and there is an incoming call, then the SCTP Server in the 2020 PINT Gateway will post this event to the SCTP Client. A window will 2021 pop up on the user's screen with options available to the user for 2022 handling of the incoming call. The user can choose to take the call, 2023 send it to voice mail, or send it to another number. 2025 For the Fax back service, for example, if the user had a separate fax 2026 machine from his or her PC, then the SCTP Server would tell the SCTP 2027 Client there is an incoming fax. The user would end or suspend his or 2028 her Internet connection, the fax would come in, and the user could 2029 then resume the Internet connection. 2031 7. Session Initiation Protocol--An Emerging Standard 2033 7.1 Overview 2035 SIP, the Session Initiation Protocol, is a simple signaling protocol 2036 for Internet conferencing and telephony. It is currently under 2037 development within the IETF MMUSIC (Multiparty Multimedia Session 2038 Control) Working Group. 2040 SIP provides the necessary mechanisms to support the following 2041 services: 2043 - call forwarding, including the equivalent of 700-, 800- and 900- 2044 type calls; 2045 - call-forwarding no answer; 2046 - call-forwarding busy; 2047 - call-forwarding unconditional; 2048 - other address-translation services; 2049 - callee and calling "numbers" delivery, where the numbers can be of 2051 Toward PSTN/Internet Inter-Networking May 1998 2053 any (preferably unique) naming scheme; 2054 - personal mobility, i.e., the ability to reach a called party under 2055 a single, location-independent address, even when the user changes 2056 terminals; 2057 - terminal-type negotiation and selection: a caller can be given a 2058 choice of how to reach a party, e.g., via Internet telephony, 2059 mobile, phone, and an answering service; 2060 - caller and callee authentication; 2061 - blind and supervised call transfer; 2062 - user location; and 2063 - invitation to multicast conferences. 2065 Extensions of SIP to allow third-party signaling (e.g., for click- 2066 to-dial-back services, fully meshed conferences and connections to 2067 Multipoint Control Units (MCUs), as well as mixed modes and the 2068 transition between those) have been specified. 2070 SIP addresses users by an email-like address and re-uses some of the 2071 infrastructure of electronic mail delivery such as DNS MX records or 2072 using SMTP EXPN for address expansion. SIP addresses (URLs) can also 2073 be embedded in Web pages. SIP is addressing-neutral, with addresses 2074 expressed as URLs of various types such as SIP, H.323 or telephone 2075 (E.164). A purely representational example of a SIP URL might be 2076 sip:12125551212@foo.example.com, where foo.example.com is the host 2077 serving as a gateway into the PSTN. 2079 SIP is independent of the packet layer and only requires an 2080 unreliable datagram service, as it provides its own reliability 2081 mechanism. While SIP typically is used over UDP or TCP, it could, 2082 without technical changes, be run over IPX, or carrier pigeons, ATM 2083 AAL5 or X.25, in rough order of desirability. 2085 SIP can set up calls "out-of-band". For example, while the SIP 2086 protocol exchanges use IP, plus UDP or TCP, the actual data transport 2087 can take place via the PSTN. This feature makes it possible to use 2088 SIP to control a PBX or send requests to a Service Control Point. The 2089 PINT services make use of this flexibility. 2091 7.2 SIP Protocol 2093 SIP is a textual client-server protocol, similar in syntax to HTTP 2094 and RTSP. Requests consist of a method (INVITE, BYE, ACK, or 2095 REGISTER), a list of parameter-value pairs describing the request and 2096 an optional request body. Parameters include the origin and 2097 destination of the call and a unique call identifier. They may 2098 indicate the caller's organization as well as the call's subject and 2099 priority. The request body contains a description of the call to be 2100 established or the conference to be joined. The description format is 2101 not prescribed by SIP; SDP is one possibility being standardized 2102 within the IETF. For the purposes of providing PINT services, an 2103 additional phone number address format is to be added to SDP. 2105 Responses indicate whether a request is still being processed, was 2106 successful, can possibly be satisfied by another node or failed. When 2108 Toward PSTN/Internet Inter-Networking May 1998 2110 a call is redirected, the response indicates the name of the node to 2111 be tried. Unsuccessful calls may also return a better time to try 2112 again. 2114 In a typical successful call, the caller sends an INVITE request to 2115 the callee. The callee accepts the call by returning a response code 2116 to the callee, which then confirms the receipt of that acceptance 2117 with an ACK request. Either side can terminate the call by sending a 2118 BYE request. 2120 Requests can be authenticated using standard HTTP password and 2121 challenge-response mechanisms. Requests and responses may also be 2122 signed and encrypted. 2124 7.3 SIP entities 2126 SIP distinguishes three kinds of entities: 2128 User agents receive and initiate calls and may forward the call. 2130 A proxy server is an intermediary program that acts as both a server 2131 and a client for the purpose of making requests on behalf of other 2132 clients. Requests are serviced internally or by passing them on, 2133 possibly after translation, to other servers. A proxy must interpret, 2134 and, if necessary, rewrite a request message before forwarding it. A 2135 proxy server may, for example, locate a user and then attempt one or 2136 more possible network addresses. 2138 Redirect server accepts a SIP request, maps the address into zero or 2139 more new addresses and returns these addresses to the client. Unlike 2140 a proxy server, it does not initiate its own SIP request. Unlike a 2141 user agent server, it does not accept calls. 2143 Proxy and redirect servers may make use of location servers that 2144 determine the current likely location of the callee. 2146 A PSTN gateway initiates phone calls between two parties. This may be 2147 a server that sends requests to an SCP in an IN environment or it may 2148 be a CTI-controlled PBX. 2150 A SIP call may traverse one or more proxy servers. 2152 The servers that control a PBX or an SCP act as user agents. A Web 2153 server may also act as a SIP user agent. 2155 7.4 Providing Call Control Functionality 2157 The SIP for PINT specification provides details on how to use SIP to 2158 initiate phone calls between two PSTN end points. (SIP can also 2159 initiate calls between Internet end points and between an Internet 2160 and PSTN end point, but this is beyond the scope of this document.) 2162 It should be noted that the SIP client for initiating such phone 2163 calls can be either at the user's location (his/her workstation) or 2165 Toward PSTN/Internet Inter-Networking May 1998 2167 can be a Web server that calls up a SIP client via a CGI program. 2168 There is no difference in operation or functionality, except that the 2169 owner of the Web server may be legally responsible for the calls 2170 made. 2172 A SIP client needs to convey two addresses to the PSTN gateway: the 2173 party making the call and the party to be called. (The party to be 2174 billed also needs to be identified; this can either be done by a SIP 2175 header or by having the server look up the appropriate party based on 2176 the two parties. This aspect is for further study.) 2178 Described below are three ways these addresses can be conveyed in 2179 SIP. In the example, the address of party A is +1-212-555-1234 and 2180 that of party B is +1-415-555-1200. (The URL types in this and other 2181 examples are representational; they may but do not have to exist.) 2183 (1) The two PSTN addresses are contained in the To header (and 2184 request-URI) and an Also header. For example: 2186 INVITE sip:1-212-555-1234@pbx.example.com 2187 To: phone:1-212-555-1234 2188 From: sip:j.doe@example.com 2189 Content-type: application/sdp 2190 Call-ID: 19970721T135107.25.181@foo.bar.com 2191 Also: phone:+1-415-555-1200 2193 v=0 2194 o=user1 53655765 2353687637 IN IP4 128.3.4.5 2195 c=PSTN E.164 +1-415-555-1200 2196 t=0 0 2197 m=audio 0 RTP/AVP 0 2199 In that case, the gateway first connects to party A and then party B, 2200 but without waiting for A to accept the call before calling B. 2202 (2) Parties A and B are indicated by separate invitations. This 2203 allows the gateway to make sure that party A is indeed available 2204 before calling party B. After calling party A, the gateway could 2205 play an announcement indicating that the call is being connected 2206 using, for example, RTSP with appropriate Conference header 2207 indicating the call. 2209 INVITE sip:1-212-555-1234@pbx.example.com 2210 To: phone:1-212-555-1234 2211 From: sip:j.doe@example.com 2212 Content-type: application/sdp 2213 Call-ID: 19970721T135107.25.181@foo.bar.com 2214 ... 2215 INVITE sip:1-415-555-1200@pbx.example.com 2216 To: phone:+1-415-555-1200 2217 From: sip:j.doe@example.com 2218 Content-type: application/sdp 2219 Call-ID: 19970721T135107.25.181@foo.bar.com 2221 Toward PSTN/Internet Inter-Networking May 1998 2223 ... 2225 (3) The two PSTN addresses are conveyed in the To header of the SIP 2226 request and the address in the SDP media description. Thus, a request 2227 may look as follows: 2229 INVITE sip:1-212-555-1234@pbx.example.com 2230 To: phone:1-212-555-1234 2231 From: sip:j.doe@example.com 2232 Content-type: application/sdp 2233 Call-ID: 19970721T135107.25.181@foo.bar.com 2235 v=0 2236 o=user1 53655765 2353687637 IN IP4 128.3.4.5 2237 c=PSTN E.164 +1-415-555-1200 2238 t=0 0 2239 m=audio 0 RTP/AVP 0 2241 Here, pbx.example.com is the name of the PSTN gateway; the call will 2242 be established between 1-212-555-1234 and +1-415-555-1200. 2244 Users can be added to an existing call by method (1) or (2). 2246 8. Overall Security Considerations 2248 Inter-networking of the Internet and PSTN necessitates the 2249 introduction of new interfaces (e.g., the A, B and E interfaces in 2250 Figure 6). To ensure that their use does not put the networks, in 2251 particular the PSTN, at additional security risk, these interfaces 2252 need to be designed with proper security considerations. Sections 2253 5.1.5 and 5.2.2.7 describe how two of the pre-PINT implementations, 2254 the Lucent and Siemens systems, handle the security aspect, 2255 respectively. 2257 Worth noting are the security requirements suggested by pre-PINT 2258 experiences. They are: 2260 +Peer entity authentication to allow a communicating entity to prove 2261 its identity to another in the network (e.g., the requesting IP-host 2262 to the PINT gateway, and the PINT gateway to the PSTN node providing 2263 the service control function). 2265 +Authorization and access control to verify if a network entity 2266 (e.g., the requesting IP-host) is allowed to use a network resource 2267 (e.g., requesting services from the PINT gateway). 2269 +Non-repudiation to account for all operations in case of doubt or 2270 dispute. 2272 +Confidentiality to avoid disclosure of information (e.g., the end 2273 user profile information and data) without the permission of its 2274 owner. 2276 Toward PSTN/Internet Inter-Networking May 1998 2278 In the course of the PINT interface development, additional 2279 requirements are likely to arise. It is imperative that the resultant 2280 interfaces include specific means to meet all the security 2281 requirements. 2283 9. Conclusion 2285 This document has provided the information relevant to the 2286 development of inter-networking interfaces between the PSTN and 2287 Internet for supporting PINT services. Specifically, it addressed 2288 technologies, architectures, and several existing pre-PINT 2289 implementations of the arrangements through which Internet 2290 applications can request and enrich PSTN telecommunications services. 2291 One key observation is that the pre-PINT implementations, being 2292 developed independently, do not inter-operate. It is a task of the 2293 PINT Working Group to define the inter-networking interfaces that 2294 will support inter-operation of the future implementations of PINT 2295 services. 2297 10. Acknowledgments 2299 The authors would like to acknowledge Scott Bradner, Igor Faynberg, 2300 Dave Oran, Scott Petrack, Allyn Romanow for their insightful comments 2301 presented to the discussions in the PINT Working Group that lead to 2302 the creation of this document. 2304 11. Appendix 2306 11.1 PSTN/IN 101 2308 11.1.1 Public Switched Telephone Network 2310 What is normally considered as "the Telephone Network" consists of a 2311 set of interconnected networks. Potentially, each of these networks 2312 could be owned by a different Network Operator. The official name for 2313 such a network is Public Switched Telecommunications Network (PSTN). 2314 A simple PSTN consists of a set of Switches (called Central Offices 2315 or Telephone Exchanges) with links interconnecting them to make up 2316 the network, along with a set of access connections by which 2317 terminals are attached. The PSTN is used to deliver calls between 2318 terminals connected to itself or to other PSTNs with which it is 2319 interconnected. Calls on the PSTN are circuit switched; that is, a 2320 bi-directional connection is made between the calling and called 2321 terminals for the duration of the call. In PSTNs the connection is 2322 usually carried through the network in digital format occupying a 2323 fixed bandwidth; this is usually 56 or 64 Kbps. The overall 2324 configuration of the PSTN is shown in Figure 16. 2326 Toward PSTN/Internet Inter-Networking May 1998 2328 /--\ 2329 ()/\()__ 2330 /__\ \ ................................. 2331 \ ! ! ! /--\ 2332 __ \ [-!-] [-!-] ! ()/\() 2333 \ \ \__[CO ]=========[CO ]==\\ ! ___/__\ 2334 [Fax]________[---] [---] \\ [-!-] / __ 2335 \\=======[CO ]____/ \ \ 2336 [---]________[Fax] 2337 Key: ___ Access Lines 2338 === Trunk Links (inter-CO user data links) 2339 ... Inter-CO signaling network links 2341 Figure 16 2343 Messages are sent between the Switches to make and dissolve 2344 connections through the network on demand and to indicate the status 2345 of terminals involved in a call; these "signaling" messages are 2346 carried over a separate (resilient) data network dedicated to this 2347 purpose. This signaling network is also known as the Common Channel 2348 Signaling (CCS) or Signaling System Number 7 (or SS7) network after 2349 the names of the signaling protocol suite used. 2351 As yet, the majority of access connections to a PSTN carry analogue 2352 signals, with simple (analogue) telephones or Facsimile machines as 2353 terminals. Call requests are indicated to the Central Office to which 2354 a telephone is connected either by a sequence of pulses or tone pairs 2355 being sent. Notifications on the status of the request are sent back 2356 to the telephone in the form of tones. Indication from a Central 2357 Office that a call is being offered to a telephone is arranged by 2358 sending an alternating voltage down the access connection which in 2359 turn causes the ringer in the telephone to sound. These access lines 2360 have a unique address associated with them and can support a single 2361 call. 2363 However, with analogue or digital multi-line connections, or 2364 Integrated Service Digital Network (ISDN) Basic or Primary Rate 2365 Interfaces (BRI or PRI), several concurrent calls are possible and a 2366 set of addresses are associated with them. The new ISDN access 2367 connections are designed so that data exchanged with the network is 2368 in multiplexed digital form, and there is an individual channel for 2369 each of the potential connections, together with a separate channel 2370 dedicated to sending and receiving call request and call alert data 2371 as well as carrying packet switched user data. These call request and 2372 call alert messages act as the equivalent of the pulses or tones that 2373 are sent when dialing, and the ringing signal that is sent to a 2374 telephone when a call is being made to it. 2376 The operation of the call request is fairly simple in most cases and 2377 is shown in Figure 17. 2379 Toward PSTN/Internet Inter-Networking May 1998 2381 /--\ 2382 () () 2383 --____ 2384 /++\ \ ................................. /--\ 2385 /----\ \ ^ v ! () () 2386 A \ [-!-] [-!-] ! -- 2387 \->[CO ]=========[CO ]==\\ v ->-/ \ 2388 [---] [---] \\ [-!-] / /----\ 2389 \\=======[CO ]____/ B 2390 [---] 2391 Key: ___ Access Lines 2392 === Trunk Links (inter-CO user data links) 2393 ... Inter-CO signaling network links 2394 CO Central Office (Telephone Exchange) 2396 Figure 17 2398 The user presses a sequence of numbers on a telephone handset 2399 (labeled A), and the telephone passes a sequence of digits (either as 2400 pulses or tone pairs) to the Central Office via the access line. The 2401 Central Office contains a processor that will be notified that the 2402 user has made a request and the digit string that is the sole 2403 parameter of the request. This digit string is taken to be the unique 2404 address of an access line connected either to itself or to another 2405 Central Office. There is a hierarchical addressing scheme, so that 2406 the digit string can be parsed easily. A call request to a terminal 2407 (labeled B) connected to a remote Central Office can be routed by 2408 examining the digit string passed; the Central Office will extract 2409 the part of the passed address that corresponds to the remote Central 2410 Office in question, and can route the request onward, forming an 2411 inter-Switch call request and passing it via the signaling network. 2412 At the same time it will allocate one of its available transmission 2413 channels towards the remote Central Office. 2415 11.1.2 Intelligent Network 2417 This scheme has been used since the 1950s, and suffices for the 2418 majority of calls. However, there are a range of other services that 2419 can be (and have been) provided, enhancing this basic call 2420 processing. Freephone or Premium Rate services (1-800 or 1-900 2421 services) are good examples of the supplementary services that have 2422 been introduced. Apart from the important feature that the cost of 2423 these calls is varied so that the caller does not pay for a free- 2424 phone call, or pays an extra charge for a premium rate call, they 2425 have the similarity that the number dialed must be translated to 2426 arrive at the "real" address of the destination terminal. They are 2427 known as number translation services, and make up the bulk of all 2428 supplementary services delivered today. 2430 These were originally programmed into each Central Office, but the 2431 complexity of maintaining the data tables on each processor grew 2432 cumbersome, so a more general solution was sought. After a 2433 considerable gestation period, the eventual solution was the 2435 Toward PSTN/Internet Inter-Networking May 1998 2437 Intelligent Network. This takes the separation of Central Offices and 2438 the network links interconnecting them a stage further. 2440 The Central Offices are considered to provide the Call Control 2441 Function (CCF). In addition, the Service Switching Function (SSF) is 2442 provided to "enhance" the operation of these Switches by detecting 2443 when a particular request has been made (such as by dialing 1-800). 2444 If this pattern is detected, the equipment implementing the SSF will 2445 send a specialized request message over the signaling network to a 2446 separate computer that implements the Service Control Function (SCF). 2447 This entity is responsible for querying service specific data (held 2448 in a unit providing the Service Data Function, or SDF), performing 2449 any digit translations necessary, and sending the details of how to 2450 proceed back to the SSF, where they are obeyed and the call is put 2451 through to the "real" destination. In many implementations, the SDF 2452 is closely coupled to the SCF. This configuration is shown in Figure 2453 18. 2455 [---] [---] [---] 2456 /--\ [SRF] [SCF] [SDF] 2457 ()/\()__ [|-!] [-!-] [-!-] 2458 /__\ \ || \.............!......!........ 2459 \ || / ! ! /--\ 2460 __ \ [|-!] [-!-] ! ()/\() 2461 \ \ \__[SSF] [CCF] ! ___/__\ 2462 [Fax]________[CCF]=========[---]==\\ [!--] / __ 2463 \\========[CCF]__/ \ \ 2464 [---]_______[Fax] 2465 Key: ___ access relationship 2466 === trunk relationship 2467 ... signaling relationship 2469 Figure 18 2471 The advantage is that there can be a much smaller number of physical 2472 units dedicated to the SCF, and as they are connected to the 2473 signaling network they can be contacted by, and can send instructions 2474 back to, all of the units providing the SSF and thus the CCF. 2476 In another enhancement, a separate entity called the Special Resource 2477 Function (SRF) was defined. Equipment implementing this function 2478 includes announcement units to play recorded messages (for example, 2479 prompts to enter digits) to callers. It will also include the tone 2480 decoders needed to capture any digits pressed by the caller in 2481 response to the prompts. It is connected to the rest of the PSTN 2482 usually via trunk data links. It will also include a signaling 2483 connection (directly or indirectly) back to the SCF, via the PSTN's 2484 core signaling network. 2486 As an example of the way that these different functional entities 2487 interact, the SCF can ask an SSF handling a call to route the caller 2488 temporarily through to an SRF. In response to instructions sent to it 2490 Toward PSTN/Internet Inter-Networking May 1998 2492 from the SCF over the signaling network, the SRF can play 2493 announcements and can collect digits that the user presses on their 2494 terminal in response to prompts they are played. Once these digits 2495 have been collected they can be passed on to the SCF via a signaling 2496 message for further processing. In normal operation, the SCF would 2497 then ask the SSF to dissolve the temporary connection between the 2498 user's terminal and the SRF. This allows the collection of account 2499 numbers or passwords (or PINs) and forms the heart of many "Calling 2500 Card" services. 2502 This pattern of user interaction is also used in a wide variety of 2503 other services where extra account information and PINs are needed. 2504 They are collected as just described and can be checked against the 2505 correct values stored in the service database prior to allowing the 2506 call to proceed. 2508 The Intelligent Network functional entities can be realized as 2509 physical units in a number of different combinations. A common 2510 configuration is shown in Figure 19. 2512 [---] [---] [---] [---] 2513 /--\ [I.P] [SCP] [SDP] [SN ] 2514 ()/\()__ [|-!] [-!-] [-!-] [--|] 2515 /__\ \ || \.............!.....!..... | 2516 \ || / ! \ | /--\ 2517 __ \ [|-!] [-!-] \ | ()/\() 2518 \ \ \__[SSP]=========[CO ]==\\ \ | ___/__\ 2519 [Fax]________[---] [---] \\ [!-|] / __ 2520 \\=======[CO ]__/ \ \ 2521 [---]_______[Fax] 2523 Key: ___ Access Lines 2524 === Trunk Links (inter-CO user data links) 2525 ... Inter-CO signaling network links 2526 SSP Service Switching Point - a unit that implements the Service 2527 Switching Function 2528 CCP Call Control Point - a unit that performs call control 2529 functions. 2530 This is normally a kind of Central Office (shown as CO above) 2531 SCP Service Control Point - a unit implementing the Service Control 2532 Function. NOTE that this is connected to the SS7 Network and 2533 uses this connection for all of its communications. 2534 I.P Intelligent Peripheral - a unit that contains specialized 2535 resources (like announcement units, tone decoders). 2536 In effect, it implements Special Resource Functions. 2537 SN Service Node 2539 Figure 19 2541 This diagram also shows a unit called a Service Node, or SN. This 2542 contains components that realize all of the operational Intelligent 2543 Network functions (SSF, SCF, SDF, and SRF). It is sometimes more 2545 Toward PSTN/Internet Inter-Networking May 1998 2547 convenient to have all of these elements in one node (for example, 2548 for operations and maintenance reasons), particularly within smaller 2549 PSTNs or where there is a relatively low level of requests for 2550 particular services. Another difference is that, as they are all co- 2551 located, proprietary protocols can be used for internal 2552 communication, rather than the full Intelligent Network Application 2553 Part (INAP) protocol used over the core signaling network between 2554 discrete units. It also differs from the "unbundled" approach in that 2555 it is connected to the COs within a PSTN as a peripheral, having only 2556 an access connection to a Central Office; there is no connection to 2557 the core signaling network. Other than this, it operates in a similar 2558 way, and can provide the same kinds of services. Information on the 2559 specification of the Intelligent Network can be found in the ITU 2560 recommendations [1], while two books ([2] and [3]) describe the 2561 system, its history, operation, and the philosophy behind it. 2563 11.2 Call Center Features 2565 A Call Center is a system that allows a company to be organized with 2566 a group of similar individuals (agents), all of whom can either make 2567 calls to, or take calls from, customers. The system distributes 2568 incoming calls to the agents based on their availability and 2569 automates the placement of outgoing calls, selecting an agent to 2570 handle the call and routing the call to them only once the call 2571 request has been made of the PSTN. 2573 The incoming call distribution feature ("automatic call 2574 distribution", or ACD) is usually coupled with a call queuing scheme. 2575 In this scheme, the callers are connected temporarily with an 2576 announcement unit that normally plays music. The calls are treated in 2577 sequence so that (once the caller is at the front of the queue) the 2578 ACD system selects the next available agent and routes the call 2579 through to them. 2581 Another feature connects a customer making an incoming call to a unit 2582 that asks them for some information on the purpose of their call, 2583 selecting the agent to handle the call based on the particular area 2584 of expertise needed; to do this, the agents are further categorized 2585 by their knowledge (or "Skill Set"). If this skill set categorization 2586 is used then by implication there will be separate queues for each of 2587 the skill sets. This user selection scheme can be used independently 2588 of the others. For example these so-called "voice navigation systems" 2589 can be used to select a particular department extension number, based 2590 on the function required by the customer; as such, they can automate 2591 the job of company telephone receptionist in routing incoming calls. 2593 Where possible, the information gleaned from the customer can be 2594 provided to the selected agent, usually via a separate networked 2595 computer connection. Similarly, if an outgoing call is being made to 2596 one of a list of customers, information on the customer and the 2597 purpose of the call can be provided to the agent selected to handle 2598 the call. Such configurations are generally called "Computer 2599 Telephony Integration" or CTI systems. Strictly, a CTI system can be 2600 arranged to handle routing of incoming calls and automation of 2602 Toward PSTN/Internet Inter-Networking May 1998 2604 outgoing calls only (also known as computer integrated telephony 2605 features), without the agents having access to a network of 2606 computers. However, the business case for combining the telephony 2607 functions of the call center with provision to the agents of 2608 computers with customer information can be compelling. 2610 This is often further combined with a company's order and service 2611 processing computer system. In this case, a call is treated as part 2612 of a business transaction, with the information to be exchanged 2613 captured as fields of a computer form. While such a computer system 2614 is not, strictly, part of a call center, integrating the company 2615 computer system with the call center is very common. This allows the 2616 details of the call to be stored on a centralized database, allowing 2617 further automated order processing, for example. It also allows the 2618 call to be transferred from one agent to another where needed, 2619 ensuring that the new agent has the information already captured. 2620 This might be useful if someone with a different area of expertise 2621 were to be needed to handle the customer's requirements. 2623 Traditionally, Call Centers have been used to support teams of agents 2624 working at a single site (or a small number of sites, with private 2625 telephony trunks interconnecting them). The site Private Automatic 2626 Branch eXchange (PABX) was integrated with a computer system to 2627 provide these features to people at that site. There can be a 2628 business case for provision of such features to distributed teams of 2629 workers as well. In particular, the possibility of providing support 2630 for people working from home has been seen as important. Some of the 2631 Call Center features have been incorporated into public telephone 2632 exchanges or Central Offices (COs) from many manufacturers as part of 2633 their "Centrex" service offerings. 2635 There are practical limitations in providing such features on COs. 2636 Apart from the procedures needed to configure these features for any 2637 telephone line that is to use them, the basic requirement that every 2638 agent must have a connection to the supporting CO can limit its 2639 usefulness. Another approach is to provide Call Center features via 2640 the Intelligent Network. The features might thus be provided over a 2641 Telephone Operator's entire network, and would mean that the Call 2642 Center could be configured centrally while still allowing agents to 2643 be located anywhere within the telephone network. It also means that 2644 the supported company can pay for the Call Center features "as they 2645 go" rather than having a high "up front" cost. 2647 12. References 2649 [1] ITU-T Q.12xx Recommendation Series, Geneva, 1995. 2651 [2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The 2652 Intelligent Network Standards, their Application to Services", 2653 McGraw-Hill, 1996. 2655 [3] T. Magedanz and R. Popesku-Zeletin, "Intelligent Networks: Basic 2656 Technology, Standards and Evolution", Intl. Thomson Computer Press, 2658 Toward PSTN/Internet Inter-Networking May 1998 2660 1996. 2662 [4] Information processing systems - Open Systems Interconnection - 2663 Specification of Abstract Syntax Notation One (ASN.1), International 2664 Organization for Standardization, International Standard 8824, 2665 December, 1987. 2667 [5] McCloghrie, K., Editor, "Structure of Management Information for 2668 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2669 RFC1902, January 1996. 2671 [6] D. Kristol and L. Montulli, RFC2109, "HTTP State Management 2672 Mechanism", February, 1997. 2674 [7] D. Zimmerman, RFC1288, "The Finger User Information Protocol", 2675 December, 1991. 2677 Author's Addresses 2679 Steve Bellovin 2680 AT&T Labs 2681 Room B135 2682 180 Park Ave. Bldg. 103 2683 Florham Park, NJ 07932-0000 2684 USA 2685 E-Mail: smb@research.att.com 2686 Telephone: +1 973 360 8656 2687 Fax: +1 973 360 8077 2689 Fred M. Burg 2690 AT&T Labs 2691 Room 1N-117 2692 307 Middletown Lincroft Road 2693 Lincroft, NJ 07738 2694 USA 2695 E-Mail: fburg@hogpb.att.com 2696 Telephone: +1 732 576 4322 2697 Fax: +1 732 576 4317 2699 Lawrence Conroy 2700 Roke Manor Research Limited 2701 IT&N-INIA Group 2702 Roke Manor, Old Salisbury Lane, 2703 Romsey, Hampshire SO51 0ZN 2704 U.K. 2705 E-mail: lwc@roke.co.uk 2706 Telephone: +44 1794 833666 2707 Fax: +44 1794 833434 2709 Paul Davidson 2710 Nortel 2711 P.O.Box 3511 Station "C" 2712 Mail Stop 242 2714 Toward PSTN/Internet Inter-Networking May 1998 2716 Ottawa, Ontario, Canada K1Y 4H7 2717 E-Mail: pauldav@nortel.ca 2718 Telephone: +1 613 763 4234 2720 A. DeSimone 2721 AT&T Labs 2722 Room 1N-113 2723 307 Middletown Lincroft Road 2724 Lincroft, NJ 07738 2725 USA 2726 E-Mail: tds@att.com 2727 Telephone: +1 732 576 5655 2728 Fax: +1 732 576 4317 2730 Murali Krishnaswamy 2731 Bell Laboratories 2732 Lucent Technologies 2733 Room 2G-527a 2734 101 Crawfords Corner Road 2735 Holmdel, NJ 07733-3030 2736 USA 2737 E-mail: murali@bell-labs.com 2738 Telephone: +1 732 949 3611 2739 Fax: +1 732 949 3210 2741 Hui-Lan Lu 2742 Bell Laboratories 2743 Lucent Technologies 2744 Room 4K-309 2745 101 Crawfords Corner Road 2746 Holmdel, NJ 07733-3030 2747 USA 2748 E-mail: hui-lan.lu@bell-labs.com 2749 Telephone: +1 732 949 0321 2750 Fax: +1 732 949 1196 2752 Henning Schulzrinne 2753 Dept. of Computer Science 2754 Columbia University 2755 New York, NY 10027 2756 USA 2757 E-Mail: schulzrinne@cs.columbia.edu 2758 Telephone: +1 212 939 7042 (@Bell Labs: 732 949 8344) 2759 Fax: +1 212 666 0140 2761 Kamlesh T. Tewani 2762 AT&T Labs 2763 Room 1K-334 2764 101, Crawfords Corner Rd. 2765 Holmdel, NJ 07733 2766 USA 2767 E-Mail: tewani@att.com 2768 Telephone: +1 732 949 5369 2769 Fax: +1 732 949 8569 2771 Toward PSTN/Internet Inter-Networking May 1998 2773 Kumar Vishwanathan 2774 Isochrone 2775 E-Mail: kumar@isochrone.com