From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2458.txt | 3363 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3363 insertions(+) create mode 100644 doc/rfc/rfc2458.txt (limited to 'doc/rfc/rfc2458.txt') diff --git a/doc/rfc/rfc2458.txt b/doc/rfc/rfc2458.txt new file mode 100644 index 0000000..1ac10c7 --- /dev/null +++ b/doc/rfc/rfc2458.txt @@ -0,0 +1,3363 @@ + + + + + + +Netowrk Working Group H. Lu +Request for Comments: 2458 Editor +Category: Informational M. Krishnaswamy + Lucent Technologies + L. Conroy + Roke Manor Research + S. Bellovin + F. Burg + A. DeSimone + K. Tewani + AT&T Labs + P. Davidson + Nortel + H. Schulzrinne + Columbia University + K. Vishwanathan + Isochrome + November 1998 + + + Toward the PSTN/Internet Inter-Networking + --Pre-PINT Implementations + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + This document contains the information relevant to the development of + the inter-networking interfaces underway in the Public Switched + Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working + Group. It addresses technologies, architectures, and several (but by + no means all) existing pre-PINT implementations of the arrangements + through which Internet applications can request and enrich PSTN + telecommunications services. The common denominator of the enriched + services (a.k.a. PINT services) is that they combine the Internet and + PSTN services in such a way that the Internet is used for non-voice + interactions, while the voice (and fax) are carried entirely over the + PSTN. One key observation is that the pre-PINT implementations, being + developed independently, do not inter-operate. It is a task of the + PINT Working Group to define the inter-networking interfaces that + + + +Lu, et. al. Informational [Page 1] + +RFC 2458 Pre-PINT Implementations November 1998 + + + will support inter-operation of the future implementations of PINT + services. + +Table of Contents + + 1. Introduction ....................................... 3 + 2. Terminology ....................................... 3 + 3. PINT Services ....................................... 4 + 4. Architectural Overview ............................... 5 + 4.1 Public Switched Telephone Network ............... 5 + 4.2 Pre-PINT Systems ............................... 9 + 5. IN-Based Solutions ............................... 20 + 5.1 The Lucent System ............................... 20 + 5.1.1 Roles of the Web Server, Service Node, and SMS ....... 20 + 5.1.2 A Click-to-Dial-Back Service Scenario ............... 21 + 5.1.3 Web Server-Service Node Interface ............... 22 + 5.1.4 Web Server-SMS Interface and SNMP MIB ............... 24 + 5.1.5 Security Considerations ........................... 26 + 5.2 Siemens Web Call Center ........................... 27 + 5.2.1 Service Description ............................... 27 + 5.2.2 Implementation ................................... 29 + 5.2.3 Derived Requirements/Lessons ..................... 35 + 6. Alternative Solutions ............................... 37 + 6.1 The AT&T System ..................................... 37 + 6.1.1 High Level Architecture ............................ 38 + 6.1.2 IP Client to CallBroker Interface .................. 39 + 6.1.3 Protocol ........................................... 40 + 6.1.4 APIs Exposed to the IP Client ..................... 41 + 6.1.5 Voice-Bridge Control API ........................ 41 + 6.2 Simple Computer Telephony Protocol ............... 41 + 6.2.1 Overview ........................................... 41 + 6.2.2 How SCTP Fits in with the Reference PINT Services .. 42 + 7. Session Initiation Protocol--An Emerging Standard .. 43 + 7.1 Overview ....................................... 43 + 7.2 SIP Protocol ....................................... 44 + 7.3 SIP Entities ....................................... 45 + 7.4 Providing Call Control Functionality ............... 46 + 8. Overall Security Considerations ..................... 47 + 9. Conclusion ....................................... 48 + 10. Acknowledgments ................................... 48 + 11. Appendix ....................................... 49 + 11.1 PSTN/IN 101 ....................................... 49 + 11.1.1 Public Switched Telephone Network ............... 49 + 11.1.2 Intelligent Network ............................... 51 + 11.2 Call Center Features ............................. 54 + + + + + + +Lu, et. al. Informational [Page 2] + +RFC 2458 Pre-PINT Implementations November 1998 + + + 12. References ....................................... 56 + Authors' Addresses ......................................... 57 + Full Copyright Statement .................................. 60 + +1. Introduction + + This document contains the information relevant to the development of + the inter-networking interfaces underway in the Public Switched + Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working + Group. It addresses technologies, architectures, and several (but by + no means all) existing pre-PINT implementations of the arrangements + through which Internet applications can request and enrich PSTN + telecommunications services. The common denominator of the enriched + services (a.k.a. PINT services) is that they combine the Internet and + PSTN services in such a way that the Internet is used for non-voice + interactions, while the voice (and fax) are carried entirely over the + PSTN. + + The organization of the document is as follows. First, the basic + terminology and a short "intuitive" description of the PINT services + are provided. The rest of the information deals, in one way or the + other, with the pre-PINT support of these services where they are + used as a benchmark. Thus, an architectural overview common to all + present solutions is presented. The flow of the document then + divides into two streams: one is dedicated to the Intelligent Network + (IN)-based solutions; the other explores alternative means (i.e., + CallBroker and Computer-Telephony Integration (CTI) approach). At + this point, the emerging standards are explored, in particular, the + Session Initiation Protocol (SIP), which promises an elegant solution + to the PINT problem. Each of the above developments is addressed in a + respective section. The final sections of the document contain the + overall security considerations, conclusion, acknowledgments, + appendix, and a set of references. The security section summarizes + the PINT security requirements derived from the pre-PINT experiences + and the appendix presents a tutorial on the PSTN, IN, and Call Center + functions. + +2. Terminology + + This document uses the following terminology: + + Authentication -- verification of the identity of a party. + + Authorization -- determination of whether or not a party has the + right to perform certain activities. + + PINT Gateway -- the PSTN node that interacts with the Internet. + + + + +Lu, et. al. Informational [Page 3] + +RFC 2458 Pre-PINT Implementations November 1998 + + + User or Customer -- the person who asks for a service request to be + issued. In the context of PINT Services, this person will use an + Internet host to make his or her request. The term "user" is also + used to describe a host originating the PINT service request on + behalf of this person. + +3. PINT Services + + This document addresses four services initially identified by the + PINT Working Group and presently supported by pre-PINT + implementations. These services are: click-to-dial-back, click-to- + fax, click-to-fax-back and voice-access-to-content. + + Note that the word "click" should not be taken literally. It is + rather used to point out that initiation of the related services + takes place on the Internet, where point and click are the most + prevalent user actions. In other words, a service request could + originate from any type of IP-based platforms. There is no + implication that these services must be implemented by a device + within the PSTN or the Internet running a Web server. + + The common denominator of the PINT services is that they combine the + Internet and PSTN services in such a way that the Internet is used + for non-voice interactions, while the voice (and fax) are carried + entirely over the PSTN. (An example of such a service is combination + of a Web-based Yellow Pages service with the ability to initiate PSTN + calls between customers and suppliers in a manner described in what + follows.) + + Some of the benefits of using the PSTN are high quality of the voice, + an ability to route the call to different locations depending on + pre-set criteria (for example, time of the day, day of the week, and + geographic location), outstanding security and reliability, and + access to flexible, low cost, and secure billing and charging + systems. The benefits of using the Internet are the uniform, well- + defined, and widely-used interfaces available anywhere, anytime. + + Click-to-Dial-Back + + With this service, a user requests (through an IP host) that the PSTN + call be established between another party and himself or herself. An + important pre-requisite for using this service is that the user has + simultaneous access to both the PSTN and Internet. + + One example of an application of this service is on-line shopping: a + user browsing through an on-line catalogue, clicks a button thus + inviting a call from a sales representative. Note that (as is the + case with the all-PSTN Free-Phone, or "800", service) flexible + + + +Lu, et. al. Informational [Page 4] + +RFC 2458 Pre-PINT Implementations November 1998 + + + billing arrangements can be implemented here on behalf of the service + provider. In addition (and also similarly to the Free-Phone/800), the + PSTN could route the call depending on the time of day, day of week, + availability of agents in different locations, and so on. + + Click-to-Fax + + With this service, a user at an IP host requests that a fax be sent + to a particular fax number. In particular this service is especially + meaningful when the fax is to be sent to someone who has only a fax + machine (but no access to the Internet). Consider, as an example, a + service scenario in which a Web user makes a reservation for a hotel + room in Beijing from a travel service page containing hotel + information of major cities around the world. Suppose a specific + Beijing hotel chosen by the user does not have Internet connection + but has a fax machine. The user fills out the hotel reservation form + and then clicks a button sending out the form to the travel service + provider, which in turn generates a fax request and sends it together + with the hotel reservation form to the PSTN. Upon receiving the + request and the associated data, the PSTN translates the data into + the proper facsimile format and delivers it to the Beijing hotel as + specified in the fax request. + + Click-to-Fax-Back + + With this service, a user at an IP host can request that a fax be + sent to him or her. (Consider the user of the previous example, who + now requests the confirmation from the Beijing Hotel. Another useful + application of the service is when size of the information that a + user intends to get is so large that downloading it to the user's PC + over the Internet will require a long time and a lot of disk space.) + + Voice-Access-to-Content + + With this service, a user at an IP host requests that certain + information on the Internet be accessed (and delivered) in an audio + form over the PSTN, using the telephone as an informational + appliance. One application of this service is to provide Web access + to the blind. (This may require special resources--available in the + PSTN--to convert the Web data into speech.) + +4. Architectural Overview + +4.1 Public Switched Telephone Network + + From an application perspective, Internet nodes are interconnected + directly, as shown in Figure 1. When two machines are to communicate, + they will have the address of the destination end system, and will + + + +Lu, et. al. Informational [Page 5] + +RFC 2458 Pre-PINT Implementations November 1998 + + + send network level datagrams, assuming that the underlying + infrastructure will deliver them as required. + + _____ + __ _____/ \_____ + [__] / \ + [----]-.-.-.-. Internet .-. + \_____ _______/ | + __ \__./ __ . + [__] / [__] | + [----]-. [----]-. + + Key: .-.-. Internet Access Link + + Figure 1 + + Where all nodes are on the same (broadcast) network, there is no need + for intervening routers; they can send and deliver packets to one + another directly. The Internet nodes are responsible for their own + communications requests, and act as peers in the communication + sessions that result. + + This contrasts with the situation in the PSTN. There, the end systems + are configured as shown in Figure 2. The end systems tend to be + specific to a particular type of traffic, so that, for example, the + majority of terminals are dedicated to carrying speech traffic + (telephones) or to carrying facsimile data (fax machines). The + terminals all connect to Central Offices (COs) via access lines, and + these COs are interconnected into a network. + + /--\ + ()/\()__ + /__\ \ ................................. + \ ! ! ! /--\ + __ \ [-!-] [-!-] ! ()/\() + \ \ \__[CO ]=========[CO ]==\\ ! ___/__\ + [Fax]________[---] [---] \\ [-!-] / __ + \\=======[CO ]____/ \ \ + [---]________[Fax] + Key: ___ Access Lines + === Trunk Links (inter-CO user data links) + ... Inter-CO signaling network links + CO Central Office (Telephone Exchange) + + Figure 2 + + + + + + +Lu, et. al. Informational [Page 6] + +RFC 2458 Pre-PINT Implementations November 1998 + + + Communications between the terminals are all "circuit switched", so a + dedicated synchronous data path (or circuit) needs to be placed + between the end terminals for carrying all communications. Arranging + for such a circuit to be made or removed (cleared) is the + responsibility of the Central Offices in the network. A user makes a + request via his or her terminal, and this request is passed on to the + "local" Central Office. The relationship between the terminals and + the local Central Offices to which they are connected is strictly + Client/Server. + + The COs are interconnected using two different types of connections. + One of these is called a trunk connection (shown as a double line in + the above figure) and is used to carry the data traffic generated by + the terminals. The other connection acts as part of a separate + network (and is shown as a dotted line in the above figure). This is + the signaling network, and is used by the Central Offices to request + a connection to be made between themselves and the destination of the + required circuit. This will be carried across the trunk link to the + "next" Central Office in the path. The path, once in place through + the PSTN, always takes the same route. This contrasts with the + Internet, where the underlying datagram nature of the infrastructure + means that data packets are carried over different routes, depending + on the combined traffic flows through the network at the time. + + The call set up process can be viewed as having two parts: one in + which a request for connection is made, and the other in which the + circuit is made across the PSTN and call data flows between the + communicating parties. This is shown in the next pair of figures (3a + and 3b). + + + /--\ + () () + --____ + /++\ \ + /----\ \ + A \ [-!-] + \->[CO ] + [---] + Time = 13:55 + + Figure 3a + + + Key: ___ Access Lines + === Trunk Links (inter-CO user data links) + ... Inter-CO signaling network links + CO Central Office (Telephone Exchange) + + + +Lu, et. al. Informational [Page 7] + +RFC 2458 Pre-PINT Implementations November 1998 + + + /--\ + () () + -- ................................. + / \<--- ^ ! ! /--\ + /----\ \ ! v ! () () + A' \ [-!-] [-!-] ! -- + \__[CO ]=========[CO ]==\\ v ->-/ \ + [---] [---] \\ [-!-] / /----\ + \\=======[CO ]____/ B' + Time = 14:00 [---] + + Figure 3b + + Figure 3 shows a particular kind of service that can be provided; + call booking. With this service, a request is sent for a connection + to be made between the A and B telephones at a specified time. The + telephone is then replaced (the request phase is terminated). At the + specified time, the CO will make a connection across the network in + the normal way, but will, first, ring the "local" or A' telephone to + inform the user that his or her call is now about to be made. + + For more complex services, the requesting telephone is often + connected via its "local" CO to a Service Node (SN), where the user + can be played prompts and can specify the parameters of his or her + request in a more flexible manner. This is shown below, in Figures + 4a and 4b. For more details of the operation of the Service Node (and + other Intelligent Network units), see the Appendix. + + When the SN is involved in the request and in the call setup process, + it appears, to the CO, to be another PSTN terminal. As such, the + initial request is routed to the Service Node, which, as an end + system, then makes two independent calls "out" to A' and B'. + + /--\ [---] + () () [SN ] + --___ [|--] + /++\ \ | + /----\ \ | + \ | + A \ [|-!] + \->[CO ] + [---] + Time = 13:55 + + Figure 4a + + + + + + +Lu, et. al. Informational [Page 8] + +RFC 2458 Pre-PINT Implementations November 1998 + + + Key: ___ Access Lines + === Trunk Links (inter-CO user data links) + ... Inter-CO signaling network links + CO Central Office (Telephone Exchange) + SN Service Node + + + /--\ [---] + () () [SN ] + -- [|--] /--\ + / \<-- | ............................... () () + /----\ \ | ^ ! ! -- + \ | / v v / \ + A' \ [|-!] [-!-] [-!-] ->-/----\ + \--[CO ] [CO ] [CO ] / + [---] [---] [---]___/ B' + Time = 14:00 + + Figure 4b + + Note that in both cases as shown in Figures 3 and 4 a similar service + can be provided in which the B' telephone is replaced by an + Intelligent Peripheral (or an Special Resource Functional entity + within a Service Node), playing an announcement. This allows a "wake + up" call to be requested, with the Intelligent Peripheral or Service + Node Special Resource playing a suitable message to telephone A' at + the specified time. Again, for more details of the operation of the + Special Resources (and other Intelligent Network units), see the + Appendix. + +4.2 Pre-PINT Systems + + Although the pre-PINT systems reported here (i.e., those developed by + AT&T, Lucent, Siemens and Nortel) vary in the details of their + operation, they exhibit similarities in the architecture. This + section highlights the common features. Specific descriptions of + these systems will follow. + + All of the systems can be seen as being quite similar to that shown + in the following diagram. In each case, the service is separated into + two parts; one for the request and another for execution of the + service. Figure 5 summarizes the process. + + + + + + + + + +Lu, et. al. Informational [Page 9] + +RFC 2458 Pre-PINT Implementations November 1998 + + + _____ + __ _____/ \_____ + [__] / \ + [-++-]-.-.>.-. Internet .-.- + \_____ _______/ . + \___/ v + [----] . + [PINT]-.- + [----] + % + v + [---] + [SN ] + [|--] + + Figure 5a + + Key: CO Central Office (Telephone Exchange) + SN Service Node + PINT PSTN/Internet Gateway + .-.-. Internet Access Link + %%% Gateway/Service Node Link + ___ PSTN Access Lines + === PSTN Trunk Links (inter-CO user data links) + ... Inter-CO signaling network links + + _____ + __ _____/ \_____ + [__] / \ + [----]-.-.-.-. Internet .-.- + \_____ _______/ . + \___/ | + [----] . + [PINT]-.- + [-%--] + % + % + /--\ [-%-] + () () [SN ] + -- [|--] /--\ + / \<-- | .................... () () + /----\ \ | ^ ! ! -- + \ | / v v / \ + A' \ [|-!] [-!-] [-!-] ->-/----\ + \--[CO ]=======[CO ]======[CO ] / + [---] [---] [---]__/ B' + + Figure 5b + + + +Lu, et. al. Informational [Page 10] + +RFC 2458 Pre-PINT Implementations November 1998 + + + Comparing Figure 4a with Figure 5a, the differences lie in the way + that the information specifying the request is delivered to the + Service Node. In the PSTN/IN method shown in the earlier diagram, the + user connects to the SN from the telephone labeled A, with the + connection being routed via the CO. In the latter case, the request + is delivered from an Internet node, via the PINT gateway, and thence + to the Service Node over a "private" link. The effect is identical, + in that the request for service is specified (although the actual + parameters used to specify the service required may differ somewhat). + + The figures depicting the respective service execution phases + (Figures 4b and 5b) show that the operation, from the IN/PSTN + perspective, is again identical. The Service Node appears to initiate + two independent calls "out" to telephones A' and B'. + + The alternative systems developed by AT&T and by Nortel allow another + option to be used in which the PINT Gateway does not have to connect + to the PSTN via a Service Node (or other Intelligent Network + component), but can instead connect directly to Central Offices that + support the actions requested by the gateway. In these alternatives, + the commands are couched at a "lower level", specifying the call + states required for the intended service connection rather than the + service identifier and the addresses involved (leaving the + Intelligent Network components to coordinate the details of the + service call on the gateway's behalf). In this way the vocabulary of + the commands is closer to that used to control Central Offices. The + difference really lies in the language used for the services + specification, and all systems can use the overall architecture + depicted in Figure 5; the only question remains whether the + Intelligent Network components are actually needed in these other + approaches. + + + + + + + + + + + + + + + + + + + + +Lu, et. al. Informational [Page 11] + +RFC 2458 Pre-PINT Implementations November 1998 + + + The following diagram (Figure 6) shows the interface architecture + involved in providing the kind of service mentioned above. + + + Internet __ __ + Server [__] _______ [__] + [W3S-]-. ___/ .-.-.-[W3C-] Internet + _________________|/.-.-.-.-. \ Terminal + / .. . \ + | Internet / . \ | + \___________ . . . / + \/___|____\_________/ + . . . + / | \ + (A) (B) (E) + . . . + _|_ _|_ _|_ + [SN ]<-(D)--[SMS]--(H)->[SCP] + [|-|] --- [-!-] + / \ ! + (C) (I) ...........(F)...!.(G). + / \ ! ! + [--|] [|-!] [-!-] + [CO ] [MSC] [SSP] + [---] [---] \|/ [---] + /--\ | |____| | /--\ + ()/\() | | ()/\() + /--\___| 1 |___/--\ + Fixed PSTN Terminal [] Fixed PSTN Terminal + Mobile Terminal + + Key: W3S HTTP (Web) Server + W3C HTTP (Web) Client/Browser + CO Central Office (Telephone Exchange) + MSC Mobile Switching Center (Mobile Network Telephone + Exchange) + SN Service Node + SSP Service Switching Point + SCP Service Control Point + SMS Service Management System + .-.-. Internet relationship + ___ PSTN Access relationship + ... PSTN "core" signaling relationship + + Figure 6 + + + + + + +Lu, et. al. Informational [Page 12] + +RFC 2458 Pre-PINT Implementations November 1998 + + + The interfaces are: + + A The interface over which Internet requests for service are + delivered to the Service Node + B The interface over which Service Management requests are sent + from the Internet to the Service Management System + C The interface over which the Service Node sends call control + requests to a connected Central Office + D The interface over which the Service Management System manages + the Service Node + E The interface over which Internet requests for service are + delivered to the Service Control Point + F The interface over which the Service Control Point sends service + call control requests to the Mobile Switching Center + G The interface over which the Service Control Point sends service + control requests to the Service Switching Point + H The interface over which the Service Management System manages + the Service Control Point + I The interface over which the Service Node sends service call + control requests to the Mobile Switching Center + + In practice, a number of the interfaces have very similar purposes to + one another. The means by which these purposes are achieved differ, + in that some of the interfaces (C and I) reflect access arrangements, + whilst others (F and G) imply a "core" signaling relationship. + However, it is possible to categorize them in terms of the "intent" + of messages sent across the interfaces. + + For example, Interfaces A and E are similar; one of the main aims of + PINT work is to ensure that they are the same. Similarly, Interfaces + D and H imply similar actions and are likely to carry similar + messages. Interfaces C, F, G, and I are all used to request that a + call be initiated, albeit via access or core signaling relationships. + + The interfaces can also be viewed in terms of the kind of components + that are involved and the bodies by which they are codified. + Interfaces A, B, and E are all going to be realized as Internet + Protocols. All of the others use existing protocols in the PSTN/IN. + Traditionally, these have been codified by different groups, and this + is likely to be the case in the PINT work. + + The general arrangements for the different systems are shown below + (Figures 7, 8, 9, and 10). They differ in the details of their + configurations, but the main tasks they perform are very similar, and + so the overall operation is similar to the generic architecture shown + in Figures 5 and 6. + + + + + +Lu, et. al. Informational [Page 13] + +RFC 2458 Pre-PINT Implementations November 1998 + + + Key for following diagrams: + + Components: + + W3C World Wide Web Client + W3S World Wide Web Server + WSA Web Server "Back End Program" Interface (CGI or Servlet + interface) + Srvlt Servlet "back end" program/objects + FS Finger Server + SCTPC Simple Computer Telephony Protocol Client + SCTPS Simple Computer Telephony Protocol Server + CBC CallBroker Client + CBS CallBroker Server + SSTPC Service Support Transport Protocol Client + SSF Service Switching Function + SCF Service Control Function + SRF Special Resource Function + CO Central Office/ Public Telephone Exchange + SSP Service Switching Point + SCP Service Control Point + SR/I.IP Special Resource/ "Internet" Intelligent Peripheral + SMS Service Management System + INAPAd Intelligent Network Application Part Adaptor + PktFlt Packet Filter (Firewall) + SNMPAg Simple Network Management Protocol Agent + + Protocols: + + P0 HyperText Transfer Protocol + P1 HTTP Server <-> "Back End Program" internal protocol + P2 CallBroker Client <-> CallBroker Server protocol (AT&T system), + or SCTP Client <-> Server protocol (Nortel system) + P3 PINT User Agent <-> PINT Gateway protocol + P4 Intra-Intelligent Network protocol (e.g., INAP) + P5 Proprietary (INAP-based) Gateway-> I.IP protocol + P6 Finger protocol + P7 Digital Subscriber Signaling 1 protocol + P8 Simple Network Management Protocol + P9 SMS <-> Service Control Point/Service Node protocol + + + + + + + + + + + +Lu, et. al. Informational [Page 14] + +RFC 2458 Pre-PINT Implementations November 1998 + + + _____ _______ _____ + |[W3C]|----(p0)-->| [W3S] |<--(p0)----|[W3C]| + |[---]| | [WSA] | |[FS.]| + |-----| | ! | |[-!-]| + | (p1) | |--\--| + | ! | ^ + | ! | (p6) + | ! | \ + | (p1) | \ + | ! | \ + |[Srvlt]| \ + |___!___| \ + ! \ + (p3) \ + Internet ! ! + .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.!.+.+.+.+.+. + PSTN/IN _______________!_________________ ____!_____ __________ + |I [PktFlt] I| |[PktFlt]| |[PktFlt]| + |N Gateway N| | ! | | ! | + |A ___________________________ A| | ! | | ! | + |P | | P| | ! | |[SNMPAg]| + -(p4)-- |A | <-(p4)-> [SCP] <-(p4)-> | A|-(p5)->|[SR/IIP]| | [SMS] | + \ |d | [-^-] | d| |[------]| | [-^-] | + \ |__| ! |__| |________| |___!____| + \ ! ! + [-v-] !-----------------(p9)-----------------! + [SSP] + [---] + ___| |______ + | | + | /--\ | /--\ + | ()/\() | ()/\() + |__/__\ |____/__\ + + + Figure 7: The Siemens Web Call Center + + + + + + + + + + + + + + + +Lu, et. al. Informational [Page 15] + +RFC 2458 Pre-PINT Implementations November 1998 + + + _____ _______ + |[W3C]|----(p0)-->| [W3S] | + |[---]| | [WSA] | + |-----| | ! | + | (p1) | + | ! | + | ! | + | ! | + | (p1) | + | ! | + |[SSTPC]|-<---------------------------------- + |___!___| ! + ! (p8) + (p3) ! + Internet ! v + .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+ + PSTN/IN _______________!__________________________________ ____!_____ + | [PktFlt] Service [PktFlt]| |[PktFlt]| + | ! Node | | ! | + | [SCF Adaptor] | | ! | + | ! | |[SNMPAg]| + |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] | + |[|--] [-^-] [---] | | [-^-] | + |_|_____________!________________________________| |___!____| + | ! ! + [-v-] (p7) !-----------------(p9)-----------------! + [CO.]____| + [---] + ___| |_______ + | | + | /--\ | /--\ + | ()/\() | ()/\() + |__/__\ |____/__\ + + Figure 8: The Lucent System + + + + + + + + + + + + + + + + +Lu, et. al. Informational [Page 16] + +RFC 2458 Pre-PINT Implementations November 1998 + + + _____ ________ + |[W3C]|----(p0)-->| [W3S] | + |[---]| | [WSA] | + |-----| | ! | + | (p1) | + | ! | + |[WS/CBS]| + |[Adaptr]| + |___!____| + ^ + (p2) + _____ ___v____ + |[CBC]| | [CBS] | + |[---]|<---(p2)-->| [---] |-<--------------------------------- + |-----| |___!____| ! + ! (p8) + (p3) ! + Internet ! v + .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+ + PSTN/IN _______________!__________________________________ ____!_____ + | [PktFlt] Service [PktFlt]| |[PktFlt]| + | ! Node | | ! | + | [SCF Adaptor] | | ! | + | ! | |[SNMPAg]| + |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] | + |[|--] [-^-] [---] | | [-^-] | + |_|_____________!________________________________| |___!____| + | ! ! + [---] (p7) !-----------------(p9)-----------------! + [CO.]____| + [---] + ___| |_______ + | | + | /--\ | /--\ + | ()/\() | ()/\() + |__/__\ |____/__\ + + Figure 9: The AT&T System + + + + + + + + + + + + + +Lu, et. al. Informational [Page 17] + +RFC 2458 Pre-PINT Implementations November 1998 + + + _____ ________ + |[W3C]|----(p0)-->| [W3S] | + |[---]| | [WSA] | + |-----| | ! | + | (p1) | + | ! | + |[WS/ ]| + |[ SCTPS]| + |[Adaptr]| + |___!____| + ^ + (p2) + _______ ___v___ + |[SCTPC]| |[SCTPS]| + |[-----]| <-(p2)--> |[-----]|-<---------------------------------- + |-------| |___!___| ! + ! (p8) + (p3) ! + Internet ! v + .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+. + PSTN/IN _______________!__________________________________ ____!_____ + | [PktFlt] Service [PktFlt]| |[PktFlt]| + | ! Node | | ! | + | [SCF Adaptor] | | ! | + | ! | |[SNMPAg]| + |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] | + |[|--] [-^-] [---] | | [-^-] | + |_|_____________!________________________________| |___!____| + | ! ! + [---] (p7) !-----------------(p9)-----------------! + [CO.]____| + [---] + ___| |_______ + | | + | /--\ | /--\ + | ()/\() | ()/\() + |__/__\ |____/__\ + + Figure 10: The Nortel System + + As these are independent systems developed by different groups, the + names of the components, unsurprisingly, don't match. Some features + are offered by one of the systems, while they aren't by others. + However, there are a number of common features. All of the systems + provide a Web-based interface (at least as an option), using "back + end" programs to construct protocols to pass onwards to the + Intelligent Network system. + + + + +Lu, et. al. Informational [Page 18] + +RFC 2458 Pre-PINT Implementations November 1998 + + + Several Intelligent Network Functional Entities are combined into a + Service Node in the Lucent, AT&T , and Nortel systems, while in the + Siemens scheme they are separate units. However, this is not + particularly important for the provision of the services they offer. + + The main difference lies in whether or not the SCF is "aware" of the + Internet interface and has been modified to be "complicit" in + supporting these Internet requests. The Siemens approach was to re- + use an existing SCP, providing a gateway function to translate as + needed. The Lucent system used a "lighter weight" SCF adapter to + terminate the Internet protocols, as the SCF was modified to support + the Internet interface directly. + + The AT&T CallBroker and Nortel SCTP Servers introduce an intermediate + protocol (labeled p2) that allows an alternative to the Web based + interface supported by the others. This protocol matches the + "CallBroker Client API", or the "SCTP Client API". These options + provide for a bi-directional protocol, with indications sent from the + Call Broker or SCTP Server to the Client as needed. This is not + easily possible using an HTTP-based scheme (and in the Siemens case, + a dedicated Finger client/server pair was used to emulate such an + interface) + + The protocol between the Internet server and the Intelligent Network + (labeled p3 in the above diagrams) differs in each of the systems. + One of the main aims of future work will be to develop a common + protocol that will support the services offered, so that the p3 + interface will allow different implementations to inter-operate. In + the Lucent, Siemens, and Nortel systems, this was an "internal" + protocol, as it was carried between entities within the Service Node + or Gateway. + + Other contrasts between the systems lie in the support for Internet + access to Service Management, and access to the Internet by Special + Resources. Internet Management access was most developed in the + Lucent system, in which a Simple Network Management Protocol (SNMP) + agent was provided to allow inter-operation with the SMS controlling + the Service Node. In the Siemens scheme, the SMS had no direct + Internet access; any management actions were carried out within the + normal PSTN management activities. As for Internet access to special + resources, this was only required by the Siemens system as part of + its support for Call Center agent notification. Equivalent + functionality would be provided in the AT&T and Nortel systems as + mentioned above, and this would in turn be associated with event + notifications being sent as part of their (p3) Internet/IN protocol. + These differences reflect the different emphases in the products as + they were developed; again, future work will have to ensure that + common protocols can be used to support the chosen services fully. + + + +Lu, et. al. Informational [Page 19] + +RFC 2458 Pre-PINT Implementations November 1998 + + +5. IN-Based Solutions + +5.1 The Lucent System + + Figure 11 depicts the overall interconnection architecture of the + Lucent prototype in support of the four PINT services. The IN-based + architecture utilizes the Service Node and Service Management System + in addition to the Web server, which enables Web-based access to the + PINT services. This section summarizes the roles of these elements + (complemented by a click-to-dial-back service scenario), outlines the + interfaces of Web Server-Service Node and Web Server-Service + Management System (i.e., the interfaces A & B), and addresses the + common security concerns. + +5.1.1 Roles of the Web Server, Service Node, and Service Management + System + + Web Server + + The Web Server stores the profiles of content providers as well as + pre-registered users. The content provider profile contains + information such as content provider ID, telephone number, and fax + number. In addition, the profile may also include service logic that + specifies, for example, the telephone (or fax) number to be reached + based on time of the day, day of the week, or geographical location + of the user, and the conditions to accept the charge of the calls. + + Similar to the content provider profile, the pre-registered user + profile contains information such as user name, password, telephone + number, and fax number. The last two pieces of information can also + be linked to time of the day and day of the week so the user can be + reached at the appropriate telephone (or fax) number accordingly. + + Service Node + + Situated in the PSTN, the SN, like the SCP, performs the service + control function [1, 2, 3]. It executes service logic and instructs + switches on how to complete a call. The SN also performs certain + switching functions (like bridging of calls) as well as a set of + specialized functions (like playing announcements, voice recognition + and text-to-speech conversion). + + Service Management System + + The SMS performs administration and management of service logic and + customer-related data on the SN. It is responsible for the + replication of content provider profiles and provision of these data + on the SN. These functions are non-real time. + + + +Lu, et. al. Informational [Page 20] + +RFC 2458 Pre-PINT Implementations November 1998 + + + Web Users + ____________ + O -------------------------- | Internet |------------------- + ------------ | + | + | + ---------------- -------------- ------------ + | Service Node | D | Service | B |Web Server| + | (SN) |------------| Management |---------------| | + | | |System (SMS)| | | + | | A -------------- | | + | |-----------------------------------------| | + ---------------- ------------ + | | + | I | C + | | + ----------- --------- + |Mobile | |Central| + |Switching| |Office | + | Center | --------- + ----------- | + | | + | | + O O + + Mobile Wireline PSTN + Users Users + + Figure 11: Overall Interconnection Architecture of the Lucent System + +5.1.2 A Click-to-Dial-Back Service Scenario + + A Web user, who has simultaneous access to the Web and telephone + services (this can be achieved, for example, by having an ISDN + connection), is browsing through a sales catalogue and deciding to + speak to a sales representative. + + When the Web user clicks a button inviting a telephone call from the + sales office, the Web Server sends a message to the SN over the A + interface, thus crossing the Internet-to-PSTN boundary. By matching + the information received from the Web Server with the content + provider profile that had been previously loaded and activated by the + SMS over the D interface, the SN recognizes the signal. + + At this point, the SN calls the Web user. The user answers the call, + hears an announcement, e.g., "Please wait, while we are connecting + you to the sale agent", and is waiting to be connected to the sale + agent. Then the SN invokes service logic as indicated in the profile. + + + +Lu, et. al. Informational [Page 21] + +RFC 2458 Pre-PINT Implementations November 1998 + + + The execution of this logic selects an appropriate sales agent to + call based on the time of the day. It is 8 P.M. in New York where + the Web user is located, and the New York sales office has closed. + The San Francisco office, however, is still open, and so the SN makes + a call to an agent in that office. Finally, the SN bridges the two + calls and establishes a two-party call between the sales agent and + the Web user. + +5.1.3 Web Server-Service Node Interface + + Lucent developed the Service Support Transfer Protocol (SSTP) for + communications between the SN and Web Server. SSTP is of a + request/response type running on top of a reliable transport layer, + such as TCP. The Web Server sends a request to the SN to invoke a + service and the SN responds with a message indicating either success + or failure. Note that SSTP engages only the service control function + [1, 2, 3] of the SN. + +5.1.3.1 Web Server to Service Node + + In this direction, three kinds of messages may be sent: the + Transaction Initiator message, the Data Message, and the End of Data + message. + + The latter two messages are needed if the service to be invoked + involves data (such as the case in click-to-fax, click-to-fax-back + and voice-access-to-content). This was so designed to handle the + varying size of data and to ensure that the size of each stream is + within the allowable size of the underlying transport packet data + unit (imposed by some implementations of TCP/IP). + + a. Transaction Initiator + + This message provides all the necessary information but data for + invoking a service. It includes the following information elements: + + + Transaction ID, which uniquely specifies a service request. The + same transaction ID should be used for all the accompanying data- + related messages, if the service request involves data. One way for + generating unique transaction IDs is to concatenate the information: + date, time, Web Server ID (uniquely assigned for each one connected + to the SN), and transaction sequence number (a cyclic counter + incremented for each service request). + + + Service ID, which specifies the service to be invoked. The service + may be click-to-dial-back, click-to-fax, click-to-fax-back or voice- + access-to-content. + + + + +Lu, et. al. Informational [Page 22] + +RFC 2458 Pre-PINT Implementations November 1998 + + + + Content Provider ID, which uniquely represents the content + provider. This information is the key to accessing the content + provider's service logic and data on the SN. + + + Content Provider Directory Number, which is the telephone or fax + number of the content provider to be called through the PSTN. + + + User Directory Number, which is the telephone or fax number of the + user requesting the service. + + + Billed Party, which specifies the party (either the user or content + provider), to be billed. + + In addition, optional parameters may be sent from the Web Server to + the SN. For example, a retry parameter may be sent to specify the + number of times the SN will attempt to complete a service request + upon failure before the transport connection times out. + + b. Data Message + + This message provides the (encapsulated) user data part of a service + request. For example, in the case of click-to-fax-back such data are + the content to be faxed to the user. Each message is composed of the + transaction ID and a data segment. The transaction ID must be the + same as that of the transaction initiator part first invoking the + service. + + c. End of Data Message + + This message contains the transaction ID and the end of data + delimiter. The transaction ID is the same as that of the relevant + transaction initiator message. + +5.1.3.2 Service Node to Web Server + + The SN must respond to a service request from the Web Server. The + response message consists of the information elements: + + transaction ID, service type, result, time, and error code. + + + Transaction ID, which is the same as that of the original service + request. + + + Service Type, which is the same as that of the original service + request. + + + Result, which is either success or failure. + + + + +Lu, et. al. Informational [Page 23] + +RFC 2458 Pre-PINT Implementations November 1998 + + + + Time, which indicates the time of the day completing the request. + + + Error Code, which gives the reason for failure. Possible reasons + for failure are content provider telephone (or fax) busy, content + provider telephone (or fax) no answer, user telephone busy, user + refusal to complete, user no answer, nuisance control limit reached, + and content provider telephone (or fax) not in the SN database. + +5.1.3.3 Usage Scenarios: Click-to-Fax and Click-to-Fax-Back + + For the click-to-fax and click-to-fax-back services, the Lucent + system implemented only the case where the data to be sent as + facsimile reside in the Web server. There are at least three messages + that need to be sent from the Web server to the Service Node for + these services. + + The first message is the Transaction Initiator that identifies the + service type as well as a unique Transaction ID. It also includes the + sender/receiver fax number. + + The next is one or more messages of the data to be faxed. Each + message carries the same unique Transaction ID as the above. + + Last comes the end of message. It consists of the Transaction ID + (again, the same as that of the messages preceding it) and the end of + data delimiter. + + Upon receiving these messages, the Service Node, equipped with the + special resource of a fax card, converts the data into the G3 format, + calls the receiver fax, and sends back the result to the Web server + immediately. Note that the receiver fax busy or no answer is + interpreted as failure. Further, while the receiver fax answering the + call is interpreted as success, it does not necessarily mean that the + fax would go through successfully. + +5.1.4 Web Server-SMS Interface and SNMP MIB + + This interface is responsible for uploading the content provider + profile from the Web Server to the SMS and for managing the + information against any possible corruption. The SN verifies the + Content Provider ID and the Content Provider Directory Number sent by + the Web Server with the content provider profile pre-loaded from the + SMS. + + The content provider profile was based on ASN.1 [4] structure and + SNMP [5] was used to set/get the object identifiers in the SMS + database. + + + + +Lu, et. al. Informational [Page 24] + +RFC 2458 Pre-PINT Implementations November 1998 + + + Following is an example of the simple MIB available on the SMS. + + inwebContProviderTable OBJECT-TYPE + SYNTAX SEQUENCE OF InwebContProviderEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + " A table containing Content Provider profiles " + := { inweb 1} + + inwebContProviderEntry OBJECT-TYPE + SYNTAX InwebContProviderEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + " A conceptual row of the inweb. Each row + contains profile of one Content Provider" + INDEX { inwebSmsNumber } + := { inwebContProviderTable 1 } + + InwebContProviderEntry := SEQUENCE { + inwebSmsNumber Integer32, + inwebContentProviderId Integer32, + inwebContentProviderPhoneNumber Integer32, + inwebContentProviderFaxNumber Integer32 + } + + inwebSmsNumber OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + " Serial number of the SMS - used for SNMP indexing " + := { inwebContProviderEntry 1 } + + inwebContentProviderId OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + " A number that uniquely identifies each Content + Provider " + := { inwebContProviderEntry 2 } + + inwebContentProviderPhoneNumber OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-create + STATUS current + + + +Lu, et. al. Informational [Page 25] + +RFC 2458 Pre-PINT Implementations November 1998 + + + DESCRIPTION + " Content Provider's Phone Number " + := { inwebContProviderEntry 3 } + + inwebContentProviderFaxNumber OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-create + STATUS current + DESCRIPTION + " Content Provider's Fax Number " + := { inwebContProviderEntry 4 } + +5.1.5 Security Considerations + + The Lucent prototype addressed the security issues concerning the + interface between the Web Server and the SN. Those concerning the + interface between the Web Server and SMS, which was based in SNMP, + were handled by the built-in security features of SNMP. + + + Secure Communication Links + + If the Network Operator (PSTN provider) is also the Web Service + provider, the Web Server and SN/SMS will communicate over a corporate + intranet. This network is almost always protected by the + corporation's firewall and so can be deemed secure. This was the case + handled by the Lucent prototype. + + Nevertheless, if different corporations serve as the Network Operator + and the Web Service Provider, then it is likely that there may not + exist a dedicated secure communication link between the Web Server + and SN/SMS. This raises serious security considerations. One possible + solution is to use Virtual Private Networks (VPN). VPN features + support authentication of the calling and called parties and + encryption of the messages sent over insecure links (such as those on + the Internet). + + + Non-Repudiation + + All transactions were logged on both the Web Server and the Service + Node to account for all operations in case of doubt or dispute. The + log information on the SN may also be used to generate bills. + + + Malicious Requests of Users + + A user may make repeated requests to a content provider directory + number maliciously. This scenario was handled by setting a Nuisance + Control Limit (NCL) on either the SN or the Web Server or both. The + NCL has two parameters: one defining the number of requests from a + + + +Lu, et. al. Informational [Page 26] + +RFC 2458 Pre-PINT Implementations November 1998 + + + user and the other the period over which these requests takes place. + + A user may also attempt to request a call from a directory number + other than that of a content provider. This scenario was handled by + verifying the directory number (and the content provider ID) against + the database on the SN containing all the content provider + information. If the directory number (or the content provider ID) was + not in the database, the request would be rejected. + +5.2 Siemens Web Call Center + +5.2.1 Service Description + + The Web Call Center is an Intelligent Network System that accepts + requests from Internet nodes for services to be provided on the PSTN. + As the name suggests, it was designed to support a cluster of + services that, taken together, provide a subset of the features of a + Call Center, with almost all user interactions provided via World + Wide Web requests and responses. See the appendix for a background + description of Call Center Features. + + From an Intelligent Network perspective, there are a number of + services that, when combined, provide the Call Center features. The + Call Center features as implemented supported the scenario in which a + customer makes a request to be called back by an agent at a time of + the customer's choosing to discuss an item of interest to him or her. + The agent will be selected based on his or her availability and + expertise in this topic; the agent will be told whom he or she is + calling and the topic of interest, and then the agent will be + connected to the customer. + + In addition, the individual services that were deployed to support + this scenario provided support for management of the list of + available agents as well. This involved allowing the agent to "log + into" and "out of" the system and to indicate whether the agent was + then ready to handle calls to the customer. The list of services, as + seen from a user perspective, follows. + + The services support: + + i) Customer Request service - the customer explores a corporate Web + site, selects a link that offers to request an agent to call the + customer back and then is redirected to the Web Call Center server. + This presents customer with a form asking for name, the telephone + number at which he or she wishes to be called, and the time at which + the call is to be made. Note will also be made of the page to which + the customer was referred to when he or she was redirected. Once the + form has been returned, the customer receives an acknowledgment page + + + +Lu, et. al. Informational [Page 27] + +RFC 2458 Pre-PINT Implementations November 1998 + + + listing the parameters he or she has entered. + + ii) Agent Registration/Logon - An agent requests a "login" page on + the Web Call Center server. The service checks whether it has a + record of an agent present at the Internet node from which th call is + made. If not, then the caller will be sent a form allowing him or her + to enter the service identity, the company's agent identifier and + password. On return, the service identity and company agent + identifier will be checked against a list of known identities. If + found, the password will be checked, and if this matches the record + held by the service then a new session record is made of this + identity and the Internet node from which the call has been made. + + NB: This is very similar to the Universal Personal Telecommunications + (UPT) service feature "register for incoming calls". It implies that + the identified person has exclusive use of the Internet node from + that point onwards, so messages for them can be directed there. + + iii) Agent Ready - an agent who has already logged on can indicate + that he or she is ready by requesting an appropriate "ready" page on + the Web Call Center Server. The service will match the agent by the + Internet node Identifier and Agent Identity passed along with the Web + request against its list of "active" agents. It will mark them as + being ready to handle calls in its list of available agents (with + their pre-defined skill set). + + iv) Agent Not Ready - an agent can request an appropriate "ready" + page on the Web Call Center Server to indicate that he or she is + temporarily not ready to handle calls. + + v) Agent Logoff - an agent can request an appropriate "Logout" page + on the Web Call Center Server to indicate that he or she is no longer + associated with a particular Internet node. The service will match + the agent by the Internet Node Identifier and Agent Identity passed + along with the Web request against its list of "active" agents. Once + found, the session record for that agent is removed and the caller is + notified of this with an acknowledgment page. + + NB: This is very similar to the UPT "unregister" service feature. + + vi) Call Center Agent Selection and Notification - When the time + that the customer selected has arrived and an available agent with + the right skills has been selected from the appropriate list, this + service will send a notification to the Internet node associated with + that agent. A dedicated server is assumed to be running on the + agent's machine that, on receiving the notification, triggers the + agent's browser into requesting a "Agent Call In" page from the Web + Call Center Server. Once the agent's machine has made this request, + + + +Lu, et. al. Informational [Page 28] + +RFC 2458 Pre-PINT Implementations November 1998 + + + he or she will be told that there is a customer to call. + + NB: This is similar to a "Message Waiting" or "Wake Up Call" service. + + Note: As implemented, the agent is led automatically into the + following service (the returned Web page includes an automatic reload + command). + + vii) Agent Instruction - a selected agent makes a request of the + "Customer Processing" page on the Web Call Center Server. The + Internet node Identifier and Agent Identity the agent uses will be + matched against a list of agents expected to handle calls, and the + instructions for the calls will be returned to the agent. + + NB: This is similar to a "Voice Mail Replay" message service, but in + this case the message is automatically generated; there is no + associated voice mail record feature accessible. + + Note: As implemented, the instructions page will include a number of + buttons, allowing the agent to view the page the customer was looking + at when he or she made the request, and to trigger the customer + callback (as described next). + + ix) Agent/Customer Telephony Callback - the agent will make a + request of a "dial-back" page on the Web Call Center Server. The + Internet node Identifier and Agent Identity he or she uses will be + matched against a list of agents expected to handle calls, and, when + the appropriate records have been found, the service will make the + telephone call through to the customer and then connect the agent to + this telephone call (using the telephone number registered in the + respective Call Center service record). + +5.2.2 Implementation + +5.2.2.1 Introduction + + The Siemens Web Call Center used an existing IN system and service + logic that supported Call Center features. The scenario it supports + is very similar to the Siemens IN-based Call Center on which it was + based; one of the goals was to minimize changes to the service + offered. It is also virtually identical to the service "Internet + Requested Telephony Dial-back" provided by the Lucent system. + + As provided via the Internet, the services involved are mostly the + same as those provided via the PSTN and IN alone. The main + differences lie in the use of the World Wide Web as an interface to + the services rather than a telephone, SSP, and Intelligent + Peripheral. Also, the feature by which a telephone call is made + + + +Lu, et. al. Informational [Page 29] + +RFC 2458 Pre-PINT Implementations November 1998 + + + between the agent and the customer is implemented within the IN + system in a different way; this is the only element in which the PSTN + is involved. + +5.2.2.2 Web Call Center Configuration + + The general arrangement for the Web Call Center system is shown in + Figure 7. The components that were added to an existing IN system to + deal with the Internet interface are described next. + + In addition to the SCP, SSP and SMS that were part of the original + IN-based system, another unit was included to send notification + messages to agents; in the IN system the agents were sent "wake up" + telephone calls when they were required to handle their next + customers' call back. This unit is called the "Internet Intelligent + Peripheral", and its use is described later under "Non-World Wide Web + Interactions". + + As there was a need to re-use as many of the existing IN components + unchanged, a Gateway unit to deal with the interface between the + Internet and the SCP was provided. This injected INAP (Intelligent + Network Application Protocol) messages into the SCP, making it think + that it had received an Initial DP trigger from an SSP. It also + intercepted the "Connect To Resource" and "Prompt and Collect" INAP + messages sent from the SCP, acting on these to return the parameters + generated by the Internet users when they filled in the forms that + triggered the service transaction. It also translated the "Play + Announcement" message sent to the Intelligent Peripheral into a form + that it could use. Finally, it passed on the INAP message used by + the SCP to trigger SSP into making the telephone call back. + +5.2.2.3 User Interaction + + In the IN/PSTN-based system, the services have contact with the + customers and agents via their telephones, SSPs, and Intelligent + Peripherals programmed to play announcements to them and to capture + their responses. These responses are indicated by DTMF tones sent by + pressing keys on the telephones. + + In this case, almost all interactions are provided via World Wide Web + requests and responses. The sequence of announcements and responses + for each service are "collapsed" into individual form filling + transactions, and the requests are not limited to digits (or "star" + and "hash"). The implications of the use of forms on service + operation are covered in more detail later (under HTTP/IN Service + mapping). + + + + + +Lu, et. al. Informational [Page 30] + +RFC 2458 Pre-PINT Implementations November 1998 + + +5.2.2.4 Service/Caller Identifiers + + When provided via the IN/PSTN-based system, the services are passed + the Calling Line Identity (CLI) of the caller and the number the + caller dials (the DN). The CLI value is used extensively to identify + the caller and (in the case of the agent) to index into service data + tables to decide what to do next. While an equivalent value to the + DN is passed to the Web-based transactions as the requested Universal + Resource Locator (URL), the CLI cannot be given reliably. The nearest + equivalent caller identifier is the IP Address of the customer or + agent's machine. However, the use of HTTP proxies means that this + "original" Internet node Address may not be available; if a proxy is + used then its IP Address will be associated with the request. + + In providing these Call Center features the customer only has one + Web-based transaction; that of providing the initial request for a + PSTN telephone callback. To do so he or she will have to fill in a + form so as to specify not only the time to be called back, but also + the telephone number to be reached. These values can be used if + needed to identify the customer, and so the problem of originating + Internet Node ambiguity is not relevant. + + With the agents, however, there are sequences of coupled + transactions, and the particular sequence must be identified. There + will be a number of such transactions being carried out at once, and + there needs to be some identifier to show which agent is being + handled in each case. + + Such an identifier is not part of a sequence of basic Web + transactions. In a Web transaction, the HTTP Client/Web Browser makes + a request, and the HTTP Server will respond to this, normally + including some content in its reply message that will be processed by + the browser, after which it closes the TCP connection. That's the end + of the transaction; the HTTP client and server cannot normally + maintain state information beyond this point. Any sequence is reduced + to a set of unrelated transactions. + + A result of this simple pattern is that any state information + reflecting longer or more complex interactions must be stored (at + least partially) in the client system. One approach is the use of + cookies [6]. These can be set by HTTP servers as part of their + response to a request, and will be sent back with all subsequent + requests for appropriate URLs as extra HTTP headers. These cookies + allow the HTTP server to identify the client in the following + requests, so that it can continue an extended session with the + client. + + + + + +Lu, et. al. Informational [Page 31] + +RFC 2458 Pre-PINT Implementations November 1998 + + + Cookies are used in providing the Internet Call Center. Persistent + cookies are installed into the Web Browser on machines that are to be + used by call center agents as a service management (pre-service) + task. The cookie value is unique to the machine and is used to index + into a list of machine IP addresses that is stored as part of the + service data. + + Also, a session cookie is stored onto the agent's machine when the + agent registers, and is cleared when he or she de-registers. This is + used to identify the agent and so the IP address of the node with + which the agent is associated (and from which the agent's subsequent + requests should originate). The services that interact with Call + Center agents use the agent session cookie value as an identifier; in + principle this is unnecessary but it does simplify the session data + lookup procedure. The rest of the services use the persistent machine + identifier in place of the CLI, indexing into their service data + using it. Both cookies are sent with each agent request; if they are + not present, then the request is redirected to other services (for + example to the agent Logon service). + +5.2.2.5 Mapping from HTTP Transactions to IN-Based Service Features + + All of the client-initiated services require user interaction. With + the IN/PSTN-based system, the majority of the services are typified + by the callers being connected to an announcement unit that plays + them a list of choices and captures their selection. The caller can + pre-dial the digits needed; in this case the prompts are not needed + and are not made. + + The pattern of operation is somewhat different in the Internet case, + as the initial HTTP request returns a response, after which the Web + transaction has ended. Where that initial response returns a form to + be filled in by the caller, subsequently submitting the form + initiates a new HTTP transaction. This is all part of one instance + of service, however. The service consists of two request/response + pairs in tandem. + + Although it is possible to design a service to handle this pair of + Web transactions as a single unit, it may be better to reconfigure + it. The design of a service that deals with two Web exchanges as a + single extended transaction is quite complex. It must maintain state + across the pair of Web exchanges, and it has to handle a number of + failure cases including dealing with time-outs and "out of time" + submission of forms. The alternative is to split the service into two + sub-features. The first of these reflects the initial request and + delivery of the form by return, with the second one dealing with + processing of the submitted form and returning any confirmation by + reply. + + + +Lu, et. al. Informational [Page 32] + +RFC 2458 Pre-PINT Implementations November 1998 + + + The services offered don't all require form-filling, and so can be + treated as a single IN feature. There are two cases where forms are + required. The first of these is the Customer Request service, while + the other one is the "Agent Registration" service. In both cases the + initial Web transaction (by which the form is requested and returned + to the client) need not involve specific service logic processing; + the initial delivery of the form to a customer or agent can be + handled by a "normal" Web Server. In both cases the service logic is + only triggered when the form is submitted; this means that, again, + each of the services can be treated as a single IN feature. + + The IN service logic that deals with these requests has a general + pattern of action. An HTTP request is received, and this triggers the + IN service logic into action. The service logic "sees" this as an + Initial DP message and starts its processing as if it had been sent + from an SSF. The SCF uses what appears to it to be an Intelligent + Peripheral to collect the parameters of the request, and then to send + back final announcements to the requesting entity. + + The main difference, from the perspective of the IN service logic + running on the SCF, is that the service does not need to instruct the + SSF to make a temporary connection to the Intelligent Peripheral. It + is as if this connection had already been made. Similarly, there is + no need to close the service transaction by sending an explicit + "Continue Execution" message to the SSF. + + The sequence of "prompt/collect" instructions used to collect service + parameters from a caller in an IN service maps quite well to a + sequence of requests to extract a data value from the HTTP request, + based on a tag. This is a fairly standard feature of Web Server CGI + or Servlet processing. Using this mapping minimizes the changes to + the service design, in that the service logic "sees" an Intelligent + Peripheral to which it sends normal "Request Report Prompt & Collect" + messages, and from which it receives data values in response. + + All services have to fit in with the underlying HTTP interaction + pattern, and so will be expected to send a final "Announce" + instruction to the Intelligent Peripheral at the end of the service; + this is done in many IN services anyway and in all of the service + features described here. These announcements form the content + returned to the Web Client. + + + + + + + + + + +Lu, et. al. Informational [Page 33] + +RFC 2458 Pre-PINT Implementations November 1998 + + +5.2.2.6 Non-World Wide Web Interactions + + There are two exceptions to the sole use of the World Wide Web for + interaction. The first one occurs in the "Message Waiting"/"Wake Up + Call" service by which the selected agent is informed of a callback + request. World Wide Web transactions are very simple; the client + browser makes a request for content associated with a particular HTTP + URL, and the server sends a response, marking the end of the + transaction. The server cannot make a spontaneous association with a + client; it must be initiated by the client request. + + While it would be possible for the server to defer closing an earlier + transaction (by not sending back all of the content specified and + leaving the TCP connection open) it was decided that an alternative + scheme would be more convenient. The "wake up call" was arranged by + an "Internet Intelligent Peripheral" sending a request to a daemon + process running on the selected agent's machine, using the Finger + protocol [7]. The daemon sent back a standard response, but in + addition the Web Browser on the agent's machine was triggered into + making a further HTTP request of the server. In this way the "Agent + Instruction" transaction is started automatically, while still + allowing it to use a normal HTTP request/response pattern. + + The second exception occurs in the final "Agent/Customer Telephony + Callback" service. While this transaction is initiated by the agent + selecting a link on the "call instructions page" returned to them, + and includes a "confirmation" page being sent back to them in an HTTP + response, the purpose of this service is to make a telephone + connection via the PSTN between the agent's telephone and the + customer's telephone. It is the only service element that involves + the PSTN directly. From an IN/PSTN perspective, the resulting + telephone connection is different from that provided in the scheme + using the IN and PSTN alone. In this case, a PSTN call is made out to + the agent's telephone, another call is made out to the customer's + telephone, and these calls are bridged. This differs from the earlier + scheme, in which the agent originated a call to the voice mail replay + system, and this call was redirected to a new destination (the + customer's telephone). As this feature differs in purpose from the + other services, and it requires a different implementation within the + IN and PSTN system, it was organized as a separate service in this + case. + + + + + + + + + + +Lu, et. al. Informational [Page 34] + +RFC 2458 Pre-PINT Implementations November 1998 + + +5.2.2.7 Security Considerations + + In the case of this system, assumptions were made that the interface + presented to requesting agents and customers was provided via a fire + wall to deal with most attacks on the IN components. The interface + appeared as a Web Server, and there was no direct access to the HTTP + documents served, nor to the servlets providing the service logic. + + The Callback service was deemed to have simpler security requirements + than other IN services as it was akin to a free phone "1-800" service + access number; the agents work for the service subscriber and are not + charged directly. Similarly, the requesting customer is not charged + for his or her request, nor for the resulting call back. Service + subscribers would be willing to pay the costs of telephone calls + generated as a result of this cluster of services, and the costs of + running the agent services could be charged directly to them. As such + the authorization for service is defined by the contract between the + service subscriber and the service provider. + + Authentication of agents was seen as a problem. As an interim + measure, cookies were used, but this scheme delivers the cookie data + as a plain text item (a header of the Web request). Secure Socket + Layer connections were required for communication with the agent + services, and this had an impact on the performance of the IN system. + +5.2.3 Derived Requirements/Lessons + + Security is seen as a major issue. A firewall was used to control + access to the IN Components. Similarly, SSL was used for + communication with the Agents, so as to protect the cookie values + that they were sending with their requests. + + For other services, it is likely that the entity from which requests + appear to originate will be charged for the service to be rendered. + This has implications in terms of authentication and authorization of + service provision at the time of the request. It is necessary for the + service to be authorized in such a way that non-repudiation is + ensured; this is likely to mean that a certificate of identity be + provided from the person making the request, and that this can be + tied in with a financial account that that person has with the + service provider. The certificate can then be stored as part of the + billing record. While the process of electronic commerce is outside + of the scope of this work, the mechanism by which a request for + confirmation of identity is passed out to the requesting user and is + delivered back to the service logic must be considered. + + + + + + +Lu, et. al. Informational [Page 35] + +RFC 2458 Pre-PINT Implementations November 1998 + + + When changing from a "pure" IN/PSTN system to one supporting requests + via the Internet, the differences in the way that clients interacted + with the services meant that the service logic had to be redesigned. + It was realized that maintaining the state of a service during its + processing was going to be a problem; this problem was side-stepped + by re-engineering the services as form processors, allowing them to + deal with fully specified requests as a single (Web) transaction. In + addition, a "normal" Web Server was used to deliver the forms to the + users. This is a change from the IN system, where the equivalent of + the form (the prompts) were sent in sequence as part of the same + service process. + + The Call Center features provided suited this change. However, this + may not be the case for other IN services. It is quite common for + services to be designed such that the user is prompted for a + response, and the service continues dependent on this response. The + Web form presents all of the options at once, so this kind of variant + prompt/collect sequence is not possible. From this, it is difficult + to see how an IN service could be reused without some degree of + modification. + + An intermediate "gateway" system was provided to "cocoon" the service + logic as far as possible from the details of the components with + which it was working. Where needed, this unit translated calls from + the service logic into commands that operated with the Internet (and + the Web Server that acted as the interface). Our experience was that + an SCP could be "spoofed" into thinking that it was operating with + other IN components in the normal way. Within the limits of the + service used, this proved simpler than was originally expected. + + Selecting this simple approach still allows a considerable range of + services to be provided while maintaining any investment in existing + IN systems. Modification of existing IN service logic was also + easier than feared. All of the services examined provided + announcements at the end of the service transaction, and this could + be used to trigger a Web response to be sent back to the requesting + Internet user. The changes to the Call Center service logic turned + out to be minor; it took as long to analyze the service and see how + it could be arranged as a sequence of "form processing" transactions + as it did to make the changes to the service logic. + + In the Siemens Web Call Center, the "Internet Intelligent Peripheral" + with which the service logic communicated was running as a separate + program on the same node. Where more complex behavior is required of + it (such as conversion of text to speech data and interface with the + PSTN) then it would almost certainly be on a separate node. If data + is transferred from the Internet in such a scheme, any intermediate + gateway would be involved in relaying the data to this node. + + + +Lu, et. al. Informational [Page 36] + +RFC 2458 Pre-PINT Implementations November 1998 + + +6. Alternative Solutions + +6.1 The AT&T System + + AT&T developed a framework for controlling voice and voice-band data + (e.g., fax) and for providing PINT services. Key to the framework is + CallBroker, a logical entity that acts on behalf of a user to set up + sessions and make requests for PSTN resources. The sessions typically + include initiation of calls between two or more end points specified + by the user. In addition to its interactions with the PSTN for call + setup, the CallBroker is responsible for other functions, when + necessary, such as authentication and usage recording. + + This section briefly discusses the protocol at the two interfaces + that need to be defined and the corresponding APIs to provide the + above services. The two interfaces are (1) the one between the + CallBroker (or Web Server) and the Service Control Function in the + Service Node in the PSTN and (2) the one between the IP client and + the CallBroker. The latter interface, in particular, will enable + service providers to extend the architecture defined here to serve as + a platform for other advanced/value-added services (to be identified + later). In addition, the view taken here is that the IP client is + more general, and implements a protocol for communication with the + CallBroker that allows full two-way communications. For example, this + is required for the cases where a called party hangs up and an + indication may be necessary to be given to the IP Client about this + status/progress. This is also necessary when conferencing to give an + indication/status of various parties joining the call. + + + + + + + + + + + + + + + + + + + + + + + +Lu, et. al. Informational [Page 37] + +RFC 2458 Pre-PINT Implementations November 1998 + + +6.1.1 High Level Architecture + + A high level architecture depicting various logical entities and the + Interfaces among these logical Entities and the IP Client is shown in + Figure 12. + + ________________ + / + 1 _____ / 2 _____ + /|________________| |________| | PSTN + |____| \ |____| + Call \ / SCF\ + Broker \ / SN \ + \_____________ + / \ + / \ + / \ + __ __ + /\ /\ + + Calling Participant + Party (Called Party) + + + Figure 12: The CallBroker Architecture + + The CallBroker, in addition to the initiation and control of calls on + behalf of the user, performs additional functions. These functions + include authenticating the IP Client, usage recording, and management + of the session for the IP Client for the telephony call. The notion + of the session requires that a client state machine be maintained in + the CallBroker. This also helps in notifying the IP Client about the + status/progress of the requests generated from the IP Client. + + From the perspective of the IP Client, the logical entities needed + for the above functions are within the CallBroker and are as shown in + Figure 13 below. These correspond to the functions already + discussed: Usage Recording Function, Session Management Function, + Voice Bridge, and the Authentication Function. The fact that some of + these functions may be physically separate from the CallBroker (such + as the Voice Bridge being in the PSTN) is not inconsistent with the + general view adopted here. Thus, the CallBroker Model mediates + requests for network services and enables us to define various value + added services in the future. + + + + + + + +Lu, et. al. Informational [Page 38] + +RFC 2458 Pre-PINT Implementations November 1998 + + + llllllllllllllll + l l + l Call Broker l Authentication + l Server l Function + l ______ l Interface 2a ______ + l | |x x xlx x x x x x x x x | | + l |______|x l |____| + l x x l + l x xl Interface 2b + lSession State lx + l Mnmgt. x l x Usage Recording + l Function l x Function + l _______ x l x ______ + l | | l x x x | | + l |_____| xl |____| + llllllllllllllll + x + x Interface 2c + x + _______ + | | + |_____| + + Bridge + + + Figure 13: Functional Entities in the Call Broker + + Various interfaces (i.e., 2a, 2b, 2c in Figure 13) between different + functional entities in the CallBroker may also be standardized. The + Session State Management Function may be physically realized as part + of the CallBroker Server. + +6.1.2 IP Client to CallBroker Interface + + Communication on the IP Client to CallBroker Interface (Interface 1 + in Figure 12) is a simple ASCII based protocol running directly on + TCP. The messages on this interface are primarily requests from the + client to the CallBroker, responses from the CallBroker to the IP + client responding to the requests and unsolicited events from the + CallBroker to the IP client. Since the communication is not strictly + transaction oriented, traditional encapsulation protocols like HTTP + cannot be used. There has been some ongoing work attempting to use + multiple concurrent HTTP POST requests to support event delivery but, + without too much difficulty, the ASCII protocol specified here can + easily be mapped to the POST payload of the HTTP protocol. + + + + + +Lu, et. al. Informational [Page 39] + +RFC 2458 Pre-PINT Implementations November 1998 + + +6.1.3 Protocol + + Basic Format + + The basic format of the protocol is as follows: + + [header]< + < + [body]< + < + < + + The header and body of the protocol are separated by 2 line feed + characters. The format of the header and the body is described + below. Line feed characters in the header or body will be escaped + using simple URL encoding. + + Header + + [session-id | 0]< + [message-id]< + [version-info]< + + All CallBroker transactions are identified by sessions. A session + does not necessarily correspond one-to-one to a TCP session. If the + IP client is attempting to initiate a new session with the CallBroker + the session-id field is populated with '0' to indicate session + creation request. Every session request needs to be accompanied by + sufficient information regarding authentication for the CallBroker to + create the session. + + Message-id represents the operation of the message. + + Version-info contains optional version information of the protocol. + This is to aid possible version mismatch detection and graceful error + recovery. + + Body + + The body of the protocol messages consists of name value pairs. These + name-value pairs are interpreted with reference to the message-id + which signifies the operation to be performed by the CallBroker. + + + + + + + + + +Lu, et. al. Informational [Page 40] + +RFC 2458 Pre-PINT Implementations November 1998 + + +6.1.4 APIs Exposed to the IP Client + + The APIs of the CallBroker exposed to the IP client are distinct and + different from the APIs that the CallBroker uses from the different + supporting subsystems including the authentication subsystem and the + usage recording subsystem. The IP client APIs enable clients to + effectively control voice conferencing. + +6.1.5 Voice-Bridge Control API + + The Voice Bridge Control API is used by CallBroker applications to + access voice bridging functionality. The API distinguishes between + sessions and calls. Calls represent actual voice calls placed from/to + the voice bridge. These calls can be grouped together in sessions. + All the calls that belong to a session are bridged. Calls have a + significance outside the scope of sessions. Every call can be + associated with multiple sessions with different weights at the same + time. The advantage of this approach is the ability to support + concepts like whispering in a conference call. Calls can also be + dropped from a conference session and bridged together in a new + session to give the notion of a sub-conference. These calls can later + be re-added to the main conference session. + +6.2 Simple Computer Telephony Protocol + +6.2.1 Overview + + The Simple Computer Telephony Protocol (SCTP) is a third party call + control protocol and as such does not comply with the PINT charter. + SCTP is described in this section to show how PINT services could be + implemented using SCTP, and where SCTP fits into the PINT + architecture. + + In addition to third party call control, SCTP also provides + subscriber (i.e., user) feature management (e.g., allows a user to + set do not disturb, call forwarding parameters), and subscriber + monitoring of terminal, line and address status. SCTP is strictly + client/server-based. It has no provisions for peer to peer + communications. SCTP runs as a TCP application protocol. It is + ASCII-based and uses sockets. The SCTP Server is usually connected to + a switch via a CTI (Computer-Telephony Integration) connection. + Because of this, feature interactions are limited to those within the + context of a single call, and not between PSTN services. The SCTP + Server within a PINT Gateway could also be connected to an SN, or an + SCP. See figures below. SCTP does NOT carry media. + + + + + + +Lu, et. al. Informational [Page 41] + +RFC 2458 Pre-PINT Implementations November 1998 + + +6.2.2 How SCTP Fits in with the Reference PINT Services + + SCTP Client as Part of a Web Server + + +------+ +--------+ +--------+ +------+ + | | | | SCTP | | | | + | |----| |-------| |----| | + | | | | | | | | + +------+ +--------+ +--------+ +------+ + User's PC Web Server/ PINT Gateway SN/SCP/Switch + CGI + + Figure 14: SCTP Client as Part of a Web Server + + In this architecture, the SCTP Client is embedded in the Web Server. + It is there for the specific purpose of initiating calls to the PSTN + based on user requests. The SCTP Server is within the PINT Gateway. + We go through the classic PINT examples: + + Click-to-dial-back: The SCTP Client issues an SCTP MakeCall to the + SCTP Server with the calling number supplied by Web page, and called + number supplied by the user. + + Click-to-fax-back: SCTP Client issues an SCTP MakeCall to the SCTP + Server with called number set to user's fax machine, and calling + number set to Web Server's fax machine, and treatment set to the URI + for the file to be faxed. The SCTP Server takes the file and feeds + it into the call just as a fax machine would. + + Click-to-fax: SCTP Client issues an SCTP MakeCall with calling number + set to user's fax machine, and called number set to Web Server's fax + machine. How the file is supplied to the user's fax machine is + outside the scope of SCTP. + + Voice-access-to-content: SCTP Client issues an SCTP MakeCall with + called number set to user's telephone number, and calling number set + to Web Server and treatment set to a URI for the file of the + particular Web page to be read to the called number. The SCTP Server + takes care of the file to voice conversion and this is fed into the + call as if it were voice. + + In all of the above cases, the SCTP Client can generate a variety of + different Web pages to send to the Web Server via CGI (Common Gateway + Interface). The content of these pages is based on the call + completion status of the CallMake SCTP action. + + + + + + +Lu, et. al. Informational [Page 42] + +RFC 2458 Pre-PINT Implementations November 1998 + + + SCTP Client Running on the User's PC + + + +------+ + HTML | | INTERNET + +-----+ /--------------| | + | |---/ +------+ + | | Web Server + | |---\ + +-----+ \ + User's PC \ SCTP +------+ +------+ + \------------| |-------| | PSTN + | | | | + +------+ +------+ + PINT Gateway SN/SCP/Switch + + + Figure 15: SCTP Client Running on the User's PC + + In this architecture, the user has an SCTP Client co-located with it. + If the user is using the telephone line for connection to a Web + Server and there is an incoming call, then the SCTP Server in the + PINT Gateway will post this event to the SCTP Client. A window will + pop up on the user's screen with options available to the user for + handling of the incoming call. The user can choose to take the call, + send it to voice mail, or send it to another number. + + For the Fax back service, for example, if the user had a separate fax + machine from his or her PC, then the SCTP Server would tell the SCTP + Client there is an incoming fax. The user would end or suspend his or + her Internet connection, the fax would come in, and the user could + then resume the Internet connection. + +7. Session Initiation Protocol--An Emerging Standard + +7.1 Overview + + SIP, the Session Initiation Protocol, is a simple signaling protocol + for Internet conferencing and telephony. It is currently under + development within the IETF MMUSIC (Multiparty Multimedia Session + Control) Working Group. + + SIP provides the necessary mechanisms to support the following + services: + + - call forwarding, including the equivalent of 700-, 800- and 900- + type calls; + - call-forwarding no answer; + + + +Lu, et. al. Informational [Page 43] + +RFC 2458 Pre-PINT Implementations November 1998 + + + - call-forwarding busy; + - call-forwarding unconditional; + - other address-translation services; + - callee and calling "numbers" delivery, where the numbers can be of + any (preferably unique) naming scheme; + - personal mobility, i.e., the ability to reach a called party under + a single, location-independent address, even when the user changes + terminals; + - terminal-type negotiation and selection: a caller can be given a + choice of how to reach a party, e.g., via Internet telephony, + mobile, phone, and an answering service; + - caller and callee authentication; + - blind and supervised call transfer; + - user location; and + - invitation to multicast conferences. + + Extensions of SIP to allow third-party signaling (e.g., for click- + to-dial-back services, fully meshed conferences and connections to + Multipoint Control Units (MCUs), as well as mixed modes and the + transition between those) have been specified. + + SIP addresses (URLs) can be embedded in Web pages. SIP is + addressing-neutral, with addresses expressed as URLs of various types + such as SIP, H.323 or telephone (E.164). A purely representational + example of a SIP URL might be sip:+12125551212@foo.example.com, where + foo.example.com is the host serving as a gateway into the PSTN. + + SIP is independent of the packet layer and only requires an + unreliable datagram service, as it provides its own reliability + mechanism. While SIP typically is used over UDP or TCP, it could, + without technical changes, be run over IPX, or carrier pigeons, ATM + AAL5 or X.25, in rough order of desirability. + + SIP can set up calls "out-of-band". For example, while the SIP + protocol exchanges use IP, plus UDP or TCP, the actual data transport + can take place via the PSTN. This feature makes it possible to use + SIP to control a PBX or send requests to a Service Control Point. The + PINT services make use of this flexibility. + +7.2 SIP Protocol + + SIP is a textual client-server protocol, similar in syntax to HTTP + and RTSP. Requests consist of a method (INVITE, BYE, ACK, or + REGISTER), a list of parameter-value pairs describing the request and + an optional request body. Parameters include the origin and + destination of the call and a unique call identifier. They may + indicate the caller's organization as well as the call's subject and + priority. The request body contains a description of the call to be + + + +Lu, et. al. Informational [Page 44] + +RFC 2458 Pre-PINT Implementations November 1998 + + + established or the conference to be joined. The description format is + not prescribed by SIP; SDP is one possibility being standardized + within the IETF. For the purposes of providing PINT services, an + additional phone number address format is to be added to SDP. + + Responses indicate whether a request is still being processed, was + successful, can possibly be satisfied by another node or failed. When + a call is redirected, the response indicates the name of the node to + be tried. Unsuccessful calls may also return a better time to try + again. + + In a typical successful call, the caller sends an INVITE request to + the callee. The callee accepts the call by returning a response code + to the callee, which then confirms the receipt of that acceptance + with an ACK request. Either side can terminate the call by sending a + BYE request. + + Requests can be authenticated using standard HTTP password and + challenge-response mechanisms. Requests and responses may also be + signed and encrypted. + +7.3 SIP entities + + SIP distinguishes three kinds of entities: + + User agents receive and initiate calls and may forward the call. + + A proxy server is an intermediary program that acts as both a server + and a client for the purpose of making requests on behalf of other + clients. Requests are serviced internally or by passing them on, + possibly after translation, to other servers. A proxy must interpret, + and, if necessary, rewrite a request message before forwarding it. A + proxy server may, for example, locate a user and then attempt one or + more possible network addresses. + + Redirect server accepts a SIP request, maps the address into zero or + more new addresses and returns these addresses to the client. Unlike + a proxy server, it does not initiate its own SIP request. Unlike a + user agent server, it does not accept calls. + + Proxy and redirect servers may make use of location servers that + determine the current likely location of the callee. + + A PSTN gateway initiates phone calls between two parties. This may be + a server that sends requests to an SCP in an IN environment or it may + be a CTI-controlled PBX. + + A SIP call may traverse one or more proxy servers. + + + +Lu, et. al. Informational [Page 45] + +RFC 2458 Pre-PINT Implementations November 1998 + + + The servers that control a PBX or an SCP act as user agents. A Web + server may also act as a SIP user agent. + +7.4 Providing Call Control Functionality + + The SIP for PINT specification provides details on how to use SIP to + initiate phone calls between two PSTN end points. (SIP can also + initiate calls between Internet end points and between an Internet + and PSTN end point, but this is beyond the scope of this document.) + + It should be noted that the SIP client for initiating such phone + calls can be either at the user's location (his/her workstation) or + can be a Web server that calls up a SIP client via a CGI program. + There is no difference in operation or functionality, except that the + owner of the Web server may be legally responsible for the calls + made. + + A SIP client needs to convey two addresses to the PSTN gateway: the + party making the call and the party to be called. (The party to be + billed also needs to be identified; this can either be done by a SIP + header or by having the server look up the appropriate party based on + the two parties. This aspect is for further study.) + + Described below are three ways these addresses can be conveyed in + SIP. In the example, the address of party A is +1-212-555-1234 and + that of party B is +1-415-555-1200. (The URL types in this and other + examples are representational; they may but do not have to exist.) + + (1) The two PSTN addresses are contained in the To header (and + request-URI) and an Also header. For example: + + INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0 + To: phone:1-212-555-1234 + From: sip:j.doe@example.com + Content-type: application/sdp + Call-ID: 19970721T135107.25.181@foo.bar.com + Also: phone:+1-415-555-1200 + + v=0 + o=user1 53655765 2353687637 IN IP4 128.3.4.5 + c=PSTN E.164 +1-415-555-1200 + t=0 0 + m=audio 0 RTP/AVP 0 + + In that case, the gateway first connects to party A and then party B, + but without waiting for A to accept the call before calling B. + + + + + +Lu, et. al. Informational [Page 46] + +RFC 2458 Pre-PINT Implementations November 1998 + + + (2) Parties A and B are indicated by separate invitations. This + allows the gateway to make sure that party A is indeed available + before calling party B. After calling party A, the gateway could + play an announcement indicating that the call is being connected + using, for example, RTSP with appropriate Conference header + indicating the call. + + INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0 + To: phone:1-212-555-1234 + From: sip:j.doe@example.com + Content-type: application/sdp + Call-ID: 19970721T135107.25.181@foo.bar.com + ... + INVITE sip:+1-415-555-1200@pbx.example.com SIP/2.0 + To: phone:+1-415-555-1200 + From: sip:j.doe@example.com + Content-type: application/sdp + Call-ID: 19970721T135107.25.181@foo.bar.com + ... + + (3) The two PSTN addresses are conveyed in the To header of the SIP + request and the address in the SDP media description. Thus, a request + may look as follows: + + INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0 + To: phone:1-212-555-1234 + From: sip:j.doe@example.com + Content-type: application/sdp + Call-ID: 19970721T135107.25.181@foo.bar.com + + v=0 + o=user1 53655765 2353687637 IN IP4 128.3.4.5 + c=PSTN E.164 +1-415-555-1200 + t=0 0 + m=audio 0 RTP/AVP 0 + + Here, pbx.example.com is the name of the PSTN gateway; the call will + be established between 1-212-555-1234 and +1-415-555-1200. + + Users can be added to an existing call by method (1) or (2). + +8. Overall Security Considerations + + Inter-networking of the Internet and PSTN necessitates the + introduction of new interfaces (e.g., the A, B and E interfaces in + Figure 6). To ensure that their use does not put the networks, in + particular the PSTN, at additional security risk, these interfaces + need to be designed with proper security considerations. Sections + + + +Lu, et. al. Informational [Page 47] + +RFC 2458 Pre-PINT Implementations November 1998 + + + 5.1.5 and 5.2.2.7 describe how two of the pre-PINT implementations, + the Lucent and Siemens systems, handle the security aspect, + respectively. + + Worth noting are the security requirements suggested by pre-PINT + experiences. They are: + + +Peer entity authentication to allow a communicating entity to prove + its identity to another in the network (e.g., the requesting IP-host + to the PINT gateway, and the PINT gateway to the PSTN node providing + the service control function). + + +Authorization and access control to verify if a network entity + (e.g., the requesting IP-host) is allowed to use a network resource + (e.g., requesting services from the PINT gateway). + + +Non-repudiation to account for all operations in case of doubt or + dispute. + + +Confidentiality to avoid disclosure of information (e.g., the end + user profile information and data) without the permission of its + owner. + + In the course of the PINT interface development, additional + requirements are likely to arise. It is imperative that the resultant + interfaces include specific means to meet all the security + requirements. + +9. Conclusion + + This document has provided the information relevant to the + development of inter-networking interfaces between the PSTN and + Internet for supporting PINT services. Specifically, it addressed + technologies, architectures, and several existing pre-PINT + implementations of the arrangements through which Internet + applications can request and enrich PSTN telecommunications services. + One key observation is that the pre-PINT implementations, being + developed independently, do not inter-operate. It is a task of the + PINT Working Group to define the inter-networking interfaces that + will support inter-operation of the future implementations of PINT + services. + +10. Acknowledgments + + The authors would like to acknowledge Scott Bradner, Igor Faynberg, + Dave Oran, Scott Petrack, Allyn Romanow for their insightful comments + presented to the discussions in the PINT Working Group that lead to + the creation of this document. + + + +Lu, et. al. Informational [Page 48] + +RFC 2458 Pre-PINT Implementations November 1998 + + +11. Appendix + +11.1 PSTN/IN 101 + +11.1.1 Public Switched Telephone Network + + What is normally considered as "the Telephone Network" consists of a + set of interconnected networks. Potentially, each of these networks + could be owned by a different Network Operator. The official name for + such a network is Public Switched Telecommunications Network (PSTN). + A simple PSTN consists of a set of Switches (called Central Offices + or Telephone Exchanges) with links interconnecting them to make up + the network, along with a set of access connections by which + terminals are attached. The PSTN is used to deliver calls between + terminals connected to itself or to other PSTNs with which it is + interconnected. Calls on the PSTN are circuit switched; that is, a + bi-directional connection is made between the calling and called + terminals for the duration of the call. In PSTNs the connection is + usually carried through the network in digital format occupying a + fixed bandwidth; this is usually 56 or 64 Kbps. The overall + configuration of the PSTN is shown in Figure 16. + + /--\ + ()/\()__ + /__\ \ ................................. + \ ! ! ! /--\ + __ \ [-!-] [-!-] ! ()/\() + \ \ \__[CO ]=========[CO ]==\\ ! ___/__\ + [Fax]________[---] [---] \\ [-!-] / __ + \\=======[CO ]____/ \ \ + [---]________[Fax] + Key: ___ Access Lines + === Trunk Links (inter-CO user data links) + ... Inter-CO signaling network links + + Figure 16 + + Messages are sent between the Switches to make and dissolve + connections through the network on demand and to indicate the status + of terminals involved in a call; these "signaling" messages are + carried over a separate (resilient) data network dedicated to this + purpose. This signaling network is also known as the Common Channel + Signaling (CCS) or Signaling System Number 7 (or SS7) network after + the names of the signaling protocol suite used. + + As yet, the majority of access connections to a PSTN carry analogue + signals, with simple (analogue) telephones or Facsimile machines as + terminals. Call requests are indicated to the Central Office to which + + + +Lu, et. al. Informational [Page 49] + +RFC 2458 Pre-PINT Implementations November 1998 + + + a telephone is connected either by a sequence of pulses or tone pairs + being sent. Notifications on the status of the request are sent back + to the telephone in the form of tones. Indication from a Central + Office that a call is being offered to a telephone is arranged by + sending an alternating voltage down the access connection which in + turn causes the ringer in the telephone to sound. These access lines + have a unique address associated with them and can support a single + call. + + However, with analogue or digital multi-line connections, or + Integrated Service Digital Network (ISDN) Basic or Primary Rate + Interfaces (BRI or PRI), several concurrent calls are possible and a + set of addresses are associated with them. The new ISDN access + connections are designed so that data exchanged with the network is + in multiplexed digital form, and there is an individual channel for + each of the potential connections, together with a separate channel + dedicated to sending and receiving call request and call alert data + as well as carrying packet switched user data. These call request and + call alert messages act as the equivalent of the pulses or tones that + are sent when dialing, and the ringing signal that is sent to a + telephone when a call is being made to it. + + The operation of the call request is fairly simple in most cases and + is shown in Figure 17. + + /--\ + () () + --____ + /++\ \ ................................. /--\ + /----\ \ ^ v ! () () + A \ [-!-] [-!-] ! -- + \->[CO ]=========[CO ]==\\ v ->-/ \ + [---] [---] \\ [-!-] / /----\ + \\=======[CO ]____/ B + [---] + Key: ___ Access Lines + === Trunk Links (inter-CO user data links) + ... Inter-CO signaling network links + CO Central Office (Telephone Exchange) + + Figure 17 + + The user presses a sequence of numbers on a telephone handset + (labeled A), and the telephone passes a sequence of digits (either as + pulses or tone pairs) to the Central Office via the access line. The + Central Office contains a processor that will be notified that the + user has made a request and the digit string that is the sole + parameter of the request. This digit string is taken to be the unique + + + +Lu, et. al. Informational [Page 50] + +RFC 2458 Pre-PINT Implementations November 1998 + + + address of an access line connected either to itself or to another + Central Office. There is a hierarchical addressing scheme, so that + the digit string can be parsed easily. A call request to a terminal + (labeled B) connected to a remote Central Office can be routed by + examining the digit string passed; the Central Office will extract + the part of the passed address that corresponds to the remote Central + Office in question, and can route the request onward, forming an + inter-Switch call request and passing it via the signaling network. + At the same time it will allocate one of its available transmission + channels towards the remote Central Office. + +11.1.2 Intelligent Network + + This scheme has been used since the 1950s, and suffices for the + majority of calls. However, there are a range of other services that + can be (and have been) provided, enhancing this basic call + processing. Freephone or Premium Rate services (1-800 or 1-900 + services) are good examples of the supplementary services that have + been introduced. Apart from the important feature that the cost of + these calls is varied so that the caller does not pay for a free- + phone call, or pays an extra charge for a premium rate call, they + have the similarity that the number dialed must be translated to + arrive at the "real" address of the destination terminal. They are + known as number translation services, and make up the bulk of all + supplementary services delivered today. + + These were originally programmed into each Central Office, but the + complexity of maintaining the data tables on each processor grew + cumbersome, so a more general solution was sought. After a + considerable gestation period, the eventual solution was the + Intelligent Network. This takes the separation of Central Offices and + the network links interconnecting them a stage further. + + The Central Offices are considered to provide the Call Control + Function (CCF). In addition, the Service Switching Function (SSF) is + provided to "enhance" the operation of these Switches by detecting + when a particular request has been made (such as by dialing 1-800). + If this pattern is detected, the equipment implementing the SSF will + send a specialized request message over the signaling network to a + separate computer that implements the Service Control Function (SCF). + This entity is responsible for querying service specific data (held + in a unit providing the Service Data Function, or SDF), performing + any digit translations necessary, and sending the details of how to + proceed back to the SSF, where they are obeyed and the call is put + through to the "real" destination. In many implementations, the SDF + is closely coupled to the SCF. This configuration is shown in Figure + 18. + + + + +Lu, et. al. Informational [Page 51] + +RFC 2458 Pre-PINT Implementations November 1998 + + + [---] [---] [---] + /--\ [SRF] [SCF] [SDF] + ()/\()__ [|-!] [-!-] [-!-] + /__\ \ || \.............!......!........ + \ || / ! ! /--\ + __ \ [|-!] [-!-] ! ()/\() + \ \ \__[SSF] [CCF] ! ___/__\ + [Fax]________[CCF]=========[---]==\\ [!--] / __ + \\========[CCF]__/ \ \ + [---]_______[Fax] + Key: ___ access relationship + === trunk relationship + ... signaling relationship + + + Figure 18 + + The advantage is that there can be a much smaller number of physical + units dedicated to the SCF, and as they are connected to the + signaling network they can be contacted by, and can send instructions + back to, all of the units providing the SSF and thus the CCF. + + In another enhancement, a separate entity called the Special Resource + Function (SRF) was defined. Equipment implementing this function + includes announcement units to play recorded messages (for example, + prompts to enter digits) to callers. It will also include the tone + decoders needed to capture any digits pressed by the caller in + response to the prompts. It is connected to the rest of the PSTN + usually via trunk data links. It will also include a signaling + connection (directly or indirectly) back to the SCF, via the PSTN's + core signaling network. + + As an example of the way that these different functional entities + interact, the SCF can ask an SSF handling a call to route the caller + temporarily through to an SRF. In response to instructions sent to it + from the SCF over the signaling network, the SRF can play + announcements and can collect digits that the user presses on their + terminal in response to prompts they are played. Once these digits + have been collected they can be passed on to the SCF via a signaling + message for further processing. In normal operation, the SCF would + then ask the SSF to dissolve the temporary connection between the + user's terminal and the SRF. This allows the collection of account + numbers or passwords (or PINs) and forms the heart of many "Calling + Card" services. + + + + + + + +Lu, et. al. Informational [Page 52] + +RFC 2458 Pre-PINT Implementations November 1998 + + + This pattern of user interaction is also used in a wide variety of + other services where extra account information and PINs are needed. + They are collected as just described and can be checked against the + correct values stored in the service database prior to allowing the + call to proceed. + + The Intelligent Network functional entities can be realized as + physical units in a number of different combinations. A common + configuration is shown in Figure 19. + + + [---] [---] [---] [---] + /--\ [I.P] [SCP] [SDP] [SN ] + ()/\()__ [|-!] [-!-] [-!-] [--|] + /__\ \ || \.............!.....!..... | + \ || / ! \ | /--\ + __ \ [|-!] [-!-] \ | ()/\() + \ \ \__[SSP]=========[CO ]==\\ \ | ___/__\ + [Fax]________[---] [---] \\ [!-|] / __ + \\=======[CO ]__/ \ \ + [---]_______[Fax] + + Key: ___ Access Lines + === Trunk Links (inter-CO user data links) + ... Inter-CO signaling network links + SSP Service Switching Point - a unit that implements the + Service Switching Function + CCP Call Control Point - a unit that performs call control + functions. + This is normally a kind of Central Office (shown as CO + above) + SCP Service Control Point - a unit implementing the Service + Control Function. NOTE that this is connected to the SS7 + Network and uses this connection for all of its + communications. + I.P Intelligent Peripheral - a unit that contains specialized + resources (like announcement units, tone decoders). + In effect, it implements Special Resource Functions. + SN Service Node + + Figure 19 + + This diagram also shows a unit called a Service Node, or SN. This + contains components that realize all of the operational Intelligent + Network functions (SSF, SCF, SDF, and SRF). It is sometimes more + convenient to have all of these elements in one node (for example, + for operations and maintenance reasons), particularly within smaller + PSTNs or where there is a relatively low level of requests for + + + +Lu, et. al. Informational [Page 53] + +RFC 2458 Pre-PINT Implementations November 1998 + + + particular services. Another difference is that, as they are all co- + located, proprietary protocols can be used for internal + communication, rather than the full Intelligent Network Application + Part (INAP) protocol used over the core signaling network between + discrete units. It also differs from the "unbundled" approach in that + it is connected to the COs within a PSTN as a peripheral, having only + an access connection to a Central Office; there is no connection to + the core signaling network. Other than this, it operates in a similar + way, and can provide the same kinds of services. Information on the + specification of the Intelligent Network can be found in the ITU + recommendations [1], while two books ([2] and [3]) describe the + system, its history, operation, and the philosophy behind it. + +11.2 Call Center Features + + A Call Center is a system that allows a company to be organized with + a group of similar individuals (agents), all of whom can either make + calls to, or take calls from, customers. The system distributes + incoming calls to the agents based on their availability and + automates the placement of outgoing calls, selecting an agent to + handle the call and routing the call to them only once the call + request has been made of the PSTN. + + The incoming call distribution feature ("automatic call + distribution", or ACD) is usually coupled with a call queuing scheme. + In this scheme, the callers are connected temporarily with an + announcement unit that normally plays music. The calls are treated in + sequence so that (once the caller is at the front of the queue) the + ACD system selects the next available agent and routes the call + through to them. + + Another feature connects a customer making an incoming call to a unit + that asks them for some information on the purpose of their call, + selecting the agent to handle the call based on the particular area + of expertise needed; to do this, the agents are further categorized + by their knowledge (or "Skill Set"). If this skill set categorization + is used then by implication there will be separate queues for each of + the skill sets. This user selection scheme can be used independently + of the others. For example these so-called "voice navigation systems" + can be used to select a particular department extension number, based + on the function required by the customer; as such, they can automate + the job of company telephone receptionist in routing incoming calls. + + Where possible, the information gleaned from the customer can be + provided to the selected agent, usually via a separate networked + computer connection. Similarly, if an outgoing call is being made to + one of a list of customers, information on the customer and the + purpose of the call can be provided to the agent selected to handle + + + +Lu, et. al. Informational [Page 54] + +RFC 2458 Pre-PINT Implementations November 1998 + + + the call. Such configurations are generally called "Computer + Telephony Integration" or CTI systems. Strictly, a CTI system can be + arranged to handle routing of incoming calls and automation of + outgoing calls only (also known as computer integrated telephony + features), without the agents having access to a network of + computers. However, the business case for combining the telephony + functions of the call center with provision to the agents of + computers with customer information can be compelling. + + This is often further combined with a company's order and service + processing computer system. In this case, a call is treated as part + of a business transaction, with the information to be exchanged + captured as fields of a computer form. While such a computer system + is not, strictly, part of a call center, integrating the company + computer system with the call center is very common. This allows the + details of the call to be stored on a centralized database, allowing + further automated order processing, for example. It also allows the + call to be transferred from one agent to another where needed, + ensuring that the new agent has the information already captured. + This might be useful if someone with a different area of expertise + were to be needed to handle the customer's requirements. + + Traditionally, Call Centers have been used to support teams of agents + working at a single site (or a small number of sites, with private + telephony trunks interconnecting them). The site Private Automatic + Branch eXchange (PABX) was integrated with a computer system to + provide these features to people at that site. There can be a + business case for provision of such features to distributed teams of + workers as well. In particular, the possibility of providing support + for people working from home has been seen as important. Some of the + Call Center features have been incorporated into public telephone + exchanges or Central Offices (COs) from many manufacturers as part of + their "Centrex" service offerings. + + There are practical limitations in providing such features on COs. + Apart from the procedures needed to configure these features for any + telephone line that is to use them, the basic requirement that every + agent must have a connection to the supporting CO can limit its + usefulness. Another approach is to provide Call Center features via + the Intelligent Network. The features might thus be provided over a + Telephone Operator's entire network, and would mean that the Call + Center could be configured centrally while still allowing agents to + be located anywhere within the telephone network. It also means that + the supported company can pay for the Call Center features "as they + go" rather than having a high "up front" cost. + + + + + + +Lu, et. al. Informational [Page 55] + +RFC 2458 Pre-PINT Implementations November 1998 + + +12. References + + [1] ITU-T Q.12xx Recommendation Series, Geneva, 1995. + + [2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The + Intelligent Network Standards, their Application to Services", + McGraw-Hill, 1996. + + [3] T. Magedanz and R. Popesku-Zeletin, "Intelligent Networks: Basic + Technology, Standards and Evolution", Intl. Thomson Computer + Press, 1996. + + [4] Information processing systems - Open Systems Interconnection - + Specification of Abstract Syntax Notation One (ASN.1), + International Organization for Standardization, International + Standard 8824, December, 1987. + + [5] McCloghrie, K., Editor, "Structure of Management Information for + Version 2 of the Simple Network Management Protocol (SNMPv2)", + RFC 1902, January 1996. + + [6] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", + RFC 2109, February 1997. + + [7] Zimmerman, D., "The Finger User Information Protocol", RFC 1288 + December 1991. + + + + + + + + + + + + + + + + + + + + + + + + + +Lu, et. al. Informational [Page 56] + +RFC 2458 Pre-PINT Implementations November 1998 + + +Authors' Addresses + + Steve Bellovin + AT&T Labs + Room E-215 + 180 Park Ave. Bldg. 103 + Florham Park, NJ 07932-0000 + USA + + Phone: +1 973 360 8656 + Fax: +1 973 360 8077 + EMail: smb@research.att.com + + + Fred M. Burg + AT&T Labs + Room 1N-117 + 307 Middletown Lincroft Road + Lincroft, NJ 07738 + USA + + Phone: +1 732 576 4322 + Fax: +1 732 576 4317 + EMail: fburg@hogpb.att.com + + + Lawrence Conroy + Roke Manor Research Limited + IT&N-INIA Group + Roke Manor, Old Salisbury Lane, + Romsey, Hampshire SO51 0ZN + U.K. + + Phone: +44 1794 833666 + Fax: +44 1794 833434 + EMail: lwc@roke.co.uk + + + Paul Davidson + Nortel + P.O.Box 3511 Station "C" + Mail Stop 242 + Ottawa, Ontario, Canada K1Y 4H7 + + Phone: +1 613 763 4234 + EMail: pauldav@nortel.ca + + + + + +Lu, et. al. Informational [Page 57] + +RFC 2458 Pre-PINT Implementations November 1998 + + + A. DeSimone + Lucent Technologies + Room 6H510 + 600-700 Mountain Avenue + Murray Hill, NJ 07974-0636 + USA + + Phone: +1 908 582 2382 + Fax: +1 908 582 1086 + E-Mail:tds@lucent.com + + + Murali Krishnaswamy + Bell Laboratories + Lucent Technologies + Room 2G-527a + 101 Crawfords Corner Road + Holmdel, NJ 07733-3030 + USA + + Phone: +1 732 949 3611 + Fax: +1 732 949 3210 + EMail: murali@bell-labs.com + + + Hui-Lan Lu + Bell Laboratories + Lucent Technologies + Room 4K-309 + 101 Crawfords Corner Road + Holmdel, NJ 07733-3030 + USA + + Phone: +1 732 949 0321 + Fax: +1 732 949 1196 + EMail: hui-lan.lu@bell-labs.com + + + Henning Schulzrinne + Dept. of Computer Science + Columbia University + New York, NY 10027 + USA + + Phone: +1 212 939 7042 (@Bell Labs: 732 949 8344) + Fax: +1 212 666 0140 + EMail: schulzrinne@cs.columbia.edu + + + + +Lu, et. al. Informational [Page 58] + +RFC 2458 Pre-PINT Implementations November 1998 + + + Kamlesh T. Tewani + AT&T Labs + Room 1K-334 + 101, Crawfords Corner Rd. + Holmdel, NJ 07733 + USA + + Phone: +1 732 949 5369 + Fax: +1 732 949 8569 + EMail: tewani@att.com + + + Kumar Vishwanathan + Isochrone + EMail: kumar@isochrone.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lu, et. al. Informational [Page 59] + +RFC 2458 Pre-PINT Implementations November 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Lu, et. al. Informational [Page 60] + -- cgit v1.2.3