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