PSTN Internet Notification (PIN) Framework [Page 1] A. Brusilovsky Internet Draft J. Buller L. Conroy V. Gurbani L. Slutsman Expires: December 1999 PSTN Internet Notification (PIN) Architecture, Services and Protocols (A Provisional Framework) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The purpose of this Internet Draft is to continue discussion on the issues involved in PSTN Internet Notification (PIN), as part of interconnecting IP and Public Switched Telephone Network (PSTN) with the intent of converging existing and creating new hybrid PSTN and IP services. PSTN initiated Service Requests, based on open well-defined protocols, will promote interoperability of both the networks and systems built by different vendors. This Internet Draft is submitted with the goal of becoming an Informational RFC. The rest of this document is as follows: Section 2 briefly describes the PIN concept. June 1999 PSTN Internet Notification (PIN) Framework [Page 2] Section 3 addresses Pre-PIN services and implementations. Section 4 gives comparative analysis of PINT and PIN architecture, focusing on similarities and differences of PINT and PIN architecture. Section 5 describes the scope of the proposed project by introducing its overall architecture, identifying the interfaces to be standardized and specifying the terminology definitions. Section 6 addresses PIN Protocol profile. Sections 7, 8, and 9 respectively address security considerations, supply references, and provide the authors addresses, as required by [11, 12]. Section 10 acknowledges individuals providing assistance in the creation of this document. 2. PIN Description The current PSTN/Internet Interfaces (PINT) WG addresses connection arrangements through which Internet applications can be used to enrich PSTN (Public Switched Telephone Network) telephony services. Some Interworking services require requests for services that come from the PSTN/IN. Essentially, these requests will be a "mirror image" of PINT requests. To provide interworking between PSTN and IP networks, it is very useful to use notifications of events happening within the PSTN to generate service requests that may then be passed on to the IP network for execution. This next section describes the kinds of events within the PSTN which initiate the process that results in making IP network service requests. It is included for information; this behavior does not have a direct impact on any resulting IP network protocol, giving only the reasons why an IP protocol exchange may be initiated. 2.1 PSTN/IN Events and Procedures PSTN/IN Call Flows are organized around actions or collections of actions called Point-In-Call (PIC). Detection Points (DPs), which are associated with the PICs, operate between the PICs, and can be the basis that can in turn be used to generate service requests for the IP network. IN furnishes "Network Intelligence" to the PSTN. Similarly, it can be utilized to initiate Service Requests to the IP network. There is an June 1999 PSTN Internet Notification (PIN) Framework [Page 3] important difference between the IN and IP: while a PSTN switch, designed to support IN PICs and DPs, can send messages to IN (this is because of the high performance of the dedicated SS7 network and associated protocols), it is highly unlikely, for reasons of cost, performance and security, that a PSTN switch will be able to exchange messages with the IP network. It is more realistic to use the SCP as the contact point with IP. In certain cases, for example (PSTN to PSTN transport via IP backbone with MEGACO Call Controller and SIGTRAN transport protocol) the Call Controller can talk to the PSTN. For that kind of architecture, it is possible to use call signaling messages/events such as Off-hook, On-hook directly for the IP interaction. As in the PINT milestone services [1], PIN studies atomic actions. These may be utilized as explicit services in their own right, as well as building blocks in the realization of more complex services. PINT and PIN complement each other, providing developers with a comprehensive set of "LEGO" type building blocks for these complex services that can deal not only with IP-initiated services in PSTN networks [1], but, also, with PSTN-initiated services in IP networks. Examples of services that that may be realized by these building blocks are: 1. Internet Call Waiting (ICW). ICW is the capability to provide incoming call notification and completion options when the Subscriber is on a dial-up IP connection [8]. 2. Internet Call Management. PSTN call notification and control options (flexible call screening, forwarding, etc.), delivered to an IP client [8]. 3. Internet Conference Management. PSTN Teleconference notification and management from an IP Client [6]. 4. Internet Conference Mediation. Pre-Teleconference (before an actual connection is made) management service from an IP client. 5. Advanced Caller ID Delivery [4]. Ordered incoming call notification to multiple Subscriber's dial-up IP connections. 6. Queue Management. Notification of the status and events of the call queue, much needed for the IP-based Automatic Call Distribution and Call Center applications [5]. June 1999 PSTN Internet Notification (PIN) Framework [Page 4] 7. Internet Call Routing (ICR). Flexible routing and control over a dial up PSTN call from an IP host. 8. Hybrid Network ACD [9] 3. Pre-PIN services and implementations. 3.1 Internet Call Waiting (ICW). Providing incoming call notification and completion options when the Subscriber is on a dial-up IP connection - Lucent [8]. Service Description When a call attempt is made to a service Subscriber who is presently on a dial up connection, they (the service Subscriber) are presented with a pop-up dialog box, that presents the caller's number and, optionally, his or her name. Internet Call Waiting solution provides a simple, graphically-oriented way to notify subscribers while connected to the Internet, of incoming calls. It allows the subscriber to accept or reject the call. Service providers can achieve the following important benefits through the use of Internet Call Waiting Service: o More calls completed. Call completion is an important aspect of the service provided by telecommunication operators. Calls that end in busy or no- answer, consume network resources. Solution like Internet Call Waiting contributes to greater call completion which lowers expense and provides value to both the consumer and service provider. o The ICW platform is the foundation to offer services: The service provider has the opportunity to enhance Internet Call Waiting with other services like Internet Follow-me, personalized call management, unified messaging service, click to return (dial) an important call, and other call management functions which integrate voice and data services. o Service providers can offer the following important benefits to subscribers through the use of Internet Call Waiting Service: ¸ Simple way to manage voice and data calls over a single telephone line. ¸ Ability to track all incoming calls while the service is active. ¸ PC Graphical Subscriber Interface provides a simple intuitive Subscriber interface and also allows easy customization. June 1999 PSTN Internet Notification (PIN) Framework [Page 5] When the Calling Party dials the ICW Subscriber's Destination Number, the Calling Party experiences the standard Call Waiting treatment, ringing, until Calling Party abandons or the Subscriber specified treatment. Subscriber treatment options and Calling Party experience are: o Refuse Call: Calling Party hears ringing until Calling Party abandons. o Hold Call: Calling Party hears [optional] announcement to hold while "other" call in progress is completed. The intent is that the Subscriber will accept the call momentarily. o Send to Voice Mail/third party number. Calling Party hears voice mail system announcements. o Accept Call: Calling Party hears ringing until they connected to the Subscriber. 3.2 Call Completion Internet Busy (CCIB) - Siemens. 3.2.1 Service Description The CCIB service allows subscribers to determine completion actions for telephony calls to a number which is currently in use (because the subscriber is logged on to the Internet) using the proposed PINT and PIN protocols. Completion actions could be, for example: o Refuse the call. o Forward the call to Voice Mail. o Forward the call to another number. o Drop Internet connection and take the telephony call. o Establish VoIP connection on terminating side to take the call. o Take details of the callee for later connection. o Take a voice message which can then be relayed to the terminating ends device. In an implementation of this service the subscriber would register for this service using the PINT protocol each time they wished to receive messages. This could be each time they log onto the Internet. This registration is stored either within the Internet or the PSTN/IN domains for later reference by a PIN CCIB service. Note that this mechanism inherently provides mobility as the June 1999 PSTN Internet Notification (PIN) Framework [Page 6] subscriber may register their location on any number. The registration process could be undertaken either : 1) With the help of the underlying PINT executive system providing the actual telephony number. 2) By the register message containing the telephony number. It is accepted this scenario has inherently greater security implications, which will need to be resolved during any implementation. Upon successful registration a 'thin' PIN server is activated, or downloaded to and then activated on, the subscriber's machine. When a call attempt is made to the telephony number on which the subscriber has registered their current connection to the Internet, the PSTN/IN detects this. Upon such a call attempt detection the PSTN/IN PIN gateway issues an invitation to the subscriber to take the call. The 'thin' PIN server on the subscribers machine receives the invitation and allows the subscriber to decide (from the list of possible options indicated above) how to handle the call. This choice is relayed in a response to the invitation in order that the PSTN/IN can act upon the subscriber's choice. 3.3 Advanced Caller ID Delivery - AT&T [7]. 3.3.1 Service Description The "Advanced Internet Caller-ID Delivery" service described, we envision being owned by a long-distance carrier provider (LDCP) such as AT&T, to which we refer as the service provider (SP). The subscriber to the service may have one or more Internet accounts (at home, at the office, etc.) and one or more telephone numbers on which they may be reached. One telephone number (normally a residential number) will be designated as the Primary Telephone Number (PTN). The PTN must be registered with the SP, and the table of alternative telephone numbers (in the order desired) will be stored in the SCP database where the PTN is the primary key. When the PTN is dialed, the list of provided telephone numbers is retrieved from the SCP, and the service performs the following steps: o Each provided telephone number, starting with the PTN is dialed. A line is considered to be unavailable if the call is not answered after a specified number of rings. o The call will be connected to the first available line. o Otherwise, the SCP sends a notification to the IP domain and June 1999 PSTN Internet Notification (PIN) Framework [Page 7] terminates the incoming call. o Each IP account is analyzed to determine whether the subscriber is on-line. If they are, a pop-up window will appear on the screen with the "clickable" Caller-ID number; therefore, the subscriber may input a phone number to receive the call and then click-to-dial the Caller-ID number. o Otherwise, if the subscriber is not on the Internet, they will be sent the email with the Caller-ID and the time of the call. 4. Similarities and differences of PIN and PINT architecture. Just like in PINT, as described in [1], in which the PINT protocol is a protocol between PINT Client and PINT Gateway (server), the PIN protocol addresses the interface between the PIN Executive System and IP-based PIN Servers. Unlike PINT, the PIN Executive System acts as a client, generating requests to be sent to the PIN Servers. It is useful to consider, in the first instance, how a PIN protocol would exist in relation to the work presently being undertaken with the PSTN/Internet Interfaces (PINT) WG. The PINT WG addresses connection arrangements through which Internet applications can request and enrich PSTN (Public Switched Telephone Network) telephony services. As such the PIN WG aims to perform a similar function in reverse, namely; address the connection arrangements through which the PSTN/IN can request and be enriched by services executing in the Internet domain. Figure 1. details this relationship schematically. PINT deals with requests for a service within the PSTN/IN domain and receives responses back from the PSTN/IN domain. PIN deals with requests from the PSTN/IN domain for a service in the Internet domain and receives responses back from the Internet domain. 5. Proposed Architecture. With the proliferation and wide acceptance of the Internet, and more so with the convergence of the Internet and PSTN, there is an increasing desire for events occurring on the PSTN domain to be propagated to the Internet domain. The PIN protocol attempts to fill this void. Entities in the Internet domain can receive the events generated by the PSTN domain and act appropriately. Since the PIN BOF the PIN architecture is often thought of as a mirror image of the PINT architecture and, we think, there is some truth in this statement. The basic motivation for PINT is to invoke telephony services from the Internet. To implement this the following June 1999 PSTN Internet Notification (PIN) Framework [Page 8] chain of events should take place: o an IP host sends a request to a server on a boundary of an IP network (PINT Gateway); o the Gateway relays the request to a telephone network, more precisely, to a PSTN Intelligence Node(SCP or Service Node) ; o triggered by this request, the intelligence node executes the service logic that controls the PSTN Switches that in turn carry out the desired telephony service. In the proposed PIN scenario the PSTN requests an entity in the Internet domain to carry out certain Internet based services (normally these services will involve interactions with Internet hosts and Gateways). The generic scenario is as follows: o a PSTN host (switch) triggers the execution of the service logic in a PSTN Intelligent node (Requesting System) on the boundary of PSTN and IP domains; o at a certain point of executing the service program, the PSTN Intelligence node (Requesting System) sends a request to the Internet (using protocol A in Figure 1, which is outside of the scope of this WG) PIN Executive System. o triggered by this (PSTN) request, the PIN Executive System invokes some service logic (q.v.) that instructs (using the PIN protocol) the PIN servers to carry out the desired PIN service. While we defer the discussion of PIN "milestone services" for later, one point may be made: these services do not have to mimic the telephony primitives like Call Forwarding, Call Waiting, etc. The PIN architecture is depicted in Figure 1. Certain basic call and connection events are detected at armed DPs and become visible to the IN service logic. The IN service logic program in the PSTN Requesting System identifies the need to request an Internet (PIN) service. As previously stated. protocol A in Figure 1 is outside of the scope of this WG. The specifications of protocol A may be better addressed in ITU-T. These requests are sent to the PIN Executive System. The PIN Executive System executes the appropriate service logic program; the program, acting as a PIN Client, communicates with appropriate PIN Servers. PIN requests may pass through zero or more PIN servers to take advantage of location service, redirection, and registration capabilities of the PIN protocol. The comparison of PIN and PINT architectures, depicted in Figure 1, June 1999 PSTN Internet Notification (PIN) Framework [Page 9] demonstrates the similarity and symmetry between PIN and PINT and reveals the data flows 5.1 Terminology definitions. This section provides more detailed definitions of the terminology used in this document. Service: A high level behavior performed within either the PSTN/IN, Internet or in conjunction in both domains. This behavior incorporates, as part of its expression, PINT and/or PIN protocol message flows, between these domains, in order to achieve the objectives of its function. Requesting Entity/Requestor: The entity (either a user or the equipment and programs that act as their agent) that constructs and sends a message requesting some action on the part of the recipient. In the context of PIN, the Requesting Entity is usually a component within the PSTN/I.N., and the recipient will be an Executive System (q.v.) within the IP network. Executive System: The entity that performs actions. In the PIN context, this entity will exist within the IP network, and will execute these actions in response to requests it receives from an entity within the PSTN/I.N. Requesting System: The entity that performs actions on behalf of PSTN/IN. In the PIN context, this entity will exist within the PSTN/IN network, and will execute these actions in response to requests it receives from the PSTN/I.N. Invocation/Request: The procedure by which a Requesting Entity can ask for an action to be executed by another (Internet Intelligence Node) entity. In the case of PIN, the Request will be initiated from a PSTN/I.N. entity, and the resulting action will be executed by an IP network entity. Reply/Response: The procedure by which an entity that has received a prior request for action can return information on the status of that request, or the disposition of the requested action. In the case of PIN, the Response will be generated by the IP Network-based PIN Gateway that received a request, and will be returned to the Requesting Entity within the PSTN/I.N. Service Subscription: The procedure by which a Requesting Entity can request (and gain approval for) the right to send subsequent Invocations of June 1999 PSTN Internet Notification (PIN) Framework [Page 10] particular actions. Note that this procedure may be implicit; there may not be a need for prior subscription for some requests, whilst for others there may be a required "pre-service" procedure (such as setting up accounts and security relationships). Service Unsubscription: The procedure by which a Requesting Entity can request that any long term relationship entered into by means of a prior subscription be dissolved. There can be many reasons for taking this step; for example, a recurring charge might be applied for the period of a subscription, or it may be that a subscriber is not going to be in a position to make requests (such as no longer having an appropriate terminal). Note that there can be circumstances in which the entity with which the subscription has been made is no longer willing to maintain the relationship with the subscriber (for example, on non payment, or usage breaches). As such, the "subscribee" may inform the subscriber that their relationship has been dissolved. In other words, subscription requests are said to be idimportant. Service Activation/Enabling: The procedure by which a Requesting Entity can inform the recipient that it is now willing to engage in transactions associated with a long term relationship to which it has previously subscribed. Service Deactivation/Disabling: The procedure by which an Requesting Entity can inform the recipient that it is temporarily unwilling to engage in transactions associated with a relationship to which it has previously subscribed. Registration of Interest (in an event or entity status or service status or disposition): The procedure by which a Requesting Entity can ask to be informed of events that occur in the domain of the recipient of this request. The events of interest can be classified in a number of ways. They may constitute changes of status of an Invoked Action, or in its disposition on completion, or in the status of some entity with which an Invocation association is not directly in place (e.g. the appearance of a user on the IP network, or their availability). This procedure can be considered to open a monitoring relationship between the requesting entity and the entity receiving the request. Where the events of interest involve other entities in addition to the receiving entity, then this will act as the representative; any procedure needed for it to glean information on the events of interest is hidden. June 1999 PSTN Internet Notification (PIN) Framework [Page 11] Notification/Indication: The procedure by which an entity that has received a prior registration of interest can inform the requesting entity of the events for which it has asked to be notified. 6. PIN Protocol profile At this early stage it is felt that there is some merit in abstraction away from explicit message flows (and their potential contents) to be used in the provision of services. We shall initially identify the atomic actions between each domain, which could be required to provide a basis for the production of practical services. There are five such generic actions, which could exist in order to provide the proposed services. These are : 1) Initiation actions. A request is sent from one domain to the other to initiate a service in that domain. In the case of PIN this request is sent from the PSTN/IN domain to Internet domain. A response message is returned to indicate the status or disposition of this requested action. 2) Data set action. A message is sent from one domain to the other which contains information, which should be stored in the other domain. 3) Data request action. A message is sent which requests information held in the other domain. This data is returned in the response message. 4) Subscription to/or Registration of interest action. A message is sent from one domain to another to request that an entity in the subscribing domain (PSTN/IN in the PIN case) be informed in the event of some future change in state of some entity in the other domain (Internet in the PIN case). 5) Notification action. A notification message is sent from the domain where a change in state of some entity has occurred, to the entity in the other domain, which has expressed an interest (via a subscription/registration mechanism) in these events. Note that a Notification is only sent within the context of a monitoring relationship that has been opened by prior EXPLICIT registration of interest; there should therefore exist NO possibility of an 'unsolicited' notification message being sent. Some readers may consider the actions described above to themselves June 1999 PSTN Internet Notification (PIN) Framework [Page 12] be 'services'. In the interests of clarity the term 'service' is defined as in the terminology section. 7. Security Considerations PIN Security Requirements are much more stringent than those in PINT. The reason for this is twofold: o A subscriber has to prove their "ownership" of a specific telephone line. This is important for privacy reasons. Unauthorized entities should know as little as possible about the activities on the subscriber's line. o The subscriber has to prove some ownership of their IP addresses (this is complicated because of the transient nature of the IP address, especially for dialup clients, while PIN requests may persist). Two questions should be asked: when a PIN server should stop sending messages to a particular, and possibly stale, IP address?; should the PIN messages be encrypted to protect the privacy of the client from the next 'owner' of the IP address? On the other hand there are PIN services that may have a similar security model to PINT. For such services the requirements stated in [1] should apply. o Peer entity authentication to allow a communicating entity to prove its identity to another in the network. o Non-repudiation to account for all operations in case of doubt or dispute. This could be achieved by logging all the information pertinent to the transaction. In addition, the PSTN network will maintain its own account of the transaction for generating bills. o Confidentiality to avoid disclosure of information without the permission of its owner. Although this is an essential requirement, it is not particular to the proposed project. o PIN Client profile verification to verify if the end user is authorized to use a service. In the course of the project execution, additional requirements are likely to arise and many more specific security work items are likely to be proposed and implemented. Some of the PIN-specific security considerations: o Cracking is a threat to any Service Provider (PSTN, Intranet, Internet). It is real danger - phone companies are common targets o Notification spoofing is one of the threats June 1999 PSTN Internet Notification (PIN) Framework [Page 13] o Existing mechanisms applied to the Internet can be implemented o Stealing a Notification is a new type of security threat 8. References [1] S. Petrack & L. Conroy, " The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services" Internet Draft, Internet Engineering Task Force, June 1999. [2] M. Handley, E. Schooler, H. Schulzrinne, & J. Rosenberg, "SIP: Session Initiation Protocol", RFC2543, Internet Engineering Task Force, March 1999. [3] H. Lu et al, "Inter-Networking--Pre-PINT Implementations", Informational RFC2458, Internet Engineering Task Force, Nov 1998. [4] L. Slutsman, "Advance Internet Caller-ID Delivery Service" Internet Draft, Internet Engineering Task Force, March 1999. [5] L. Slutsman, "On Call Queuing in PINT" PINT WG presentation, December 7-11, 1998 [6] L. Slutsman, "Conference Call Services for PINT" Internet Draft, Internet Engineering Task Force, April, 1999 [7] A. Brusilovsky, V. Gurbani, A. Jain, D. Varney, "Need for PSTN Internet Notification (PIN) Services. A Proposal for a new Working Group" Internet Draft, Internet Engineering Task Force, February 1999. [8] A. Brusilovsky, E. Gausmann, V. Gurbani, A. Jain, "A Proposal for Internet Call Waiting Service using SIP. An Implementation Report." Internet Draft, Internet Engineering Task Force, January 1999. [9] C. Gao, A. Brusilovsky, J. Swinger, "Hybrid Network ACD" Intelligent Network Forum, IN/IP Working Group, London, May 1999 10] J.Rosenberg, H.Schulzrinne, "SIP For Presence", Internet Draft, Internet Engineering Task Force, March, 1999 [11] S.Bradner, "The Internet Standards Process", RFC2026 [12] J. Postel, "Instruction to RFC Authors", RFC 2223 [13] S. Petrack, "IP Access to PSTN Services: Basic Service Requirements, Definitions, and Architecture", Internet Draft, Internet Engineering Task Force June 1999 PSTN Internet Notification (PIN) Framework [Page 14] 9. Authors' Addresses Alec Brusilovsky E-mail: abrusilovsky@lucent.com Telephone: +1-630-713-8401 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA Jim Buller E-mail: jim.buller@roke.co.uk Telephone: +44 (0)1794833666 Fax: +44 (0)1794833434 Siemens Roke Manor Research Ltd., Roke Manor, Old Salisbury Lane Romsey, Hampshire U.K. SO51 0ZN Lawrence Conroy E-mail: lwc@roke.co.uk Telephone: +44 (1794) 833666 Fax: +44 (1794) 833434 Siemens Roke Manor Research Roke Manor Old Salisbury Lane Romsey, Hampshire U.K. SO51 0ZN Vijay Gurbani E-mail: vkg@lucent.com Telephone: +1-630-224-0216 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA Lev Slutsman E-mail: Lslutsman@att.com Telephone: 732-420-3756 Fax: AT&T Labs Room D5-3D26 June 1999 PSTN Internet Notification (PIN) Framework [Page 15] 200 Laurel Avenue S, Middletown, NJ, USA 07748 Glossary ACD Automatic Call Distribution ACID Advanced Caller Identification Delivery CCIB Call Completion Internet Busy DN Destination Number DP Detection Point ICR Internet Call Routing ICW Internet Call Waiting IN Intelligent Network LDCP Long Distance Carrier Provider MGCP Media Gateway Control Protocol NPL Notification Processing Language PIC Point-In-Call PTN Principal Telephone Number PSTN Public Switched Telephone Network SCP Service Control Point SN Service Node SP Service Provider VoIP Voice over IP (Internet Protocol) 10. Acknowledgments The authors would like to acknowledge Igor Faynberg, Hui-Lan Lu and Jonathan Rosenberg for their contributions to the creation of this document. Our special thanks to Steve Bellovin (AT&T), Corrado Moiso (CSELT), Lyndon Ong (Nortel) and Henry Sinnreich (MCI) for their insightful comments and help with this Internet Draft. June 1999 PSTN Internet Notification (PIN) Framework [Page 16] Figures: /\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\/\/\ ___________ \ __/___ ___\_______ \ | PINT | PINT \ PINT | PINT | | Exec | Telephone / | client |<---------->| server |gatewy|===| System | Network \ |_________| protocol / cloud |______| |_________| Cloud / \ \ / \ /\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/\/\/ /\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\/\/\ ___________ \ __/___ ____\_______ \ | PIN | PIN \ PIN |Exec | |Requesting| Telephone / | server |<---------->| gateway |System|=A=| System | Network \ |_________| protocol / cloud |______| |__________| Cloud / \ \ / \ /\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/\/\/\ /-----------------------------------< < Direction of the PIN Service Flow < \-----------------------------------< Figure 1 June 1999