PINT Working Group J. Buller INTERNET-DRAFT Siemens Roke Manor Research Ltd. Category: Informational Expires: 22nd September 1999 A proposal for the provisioning of PSTN initiated services running on the Internet Status of this Memo This is an Internet-Draft and is in full conformance with all the provisions of section 10 of RFC2026. This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (c) The Internet Society (1999). All rights reserved. Abstract This Internet Draft has arisen out of work concentrating on the interconnection of IP and the Public Switched Telephone Network (PSTN) undertaken within the PINT working group. Efforts within this group have, to date, concentrated on the initiation of PSTN services from the Internet. This Internet Draft aims to describe a possible architecture for the implementation of services initiated from the PSTN such as, but not limited to, Internet Call Waiting (ICW). It also identifies the possibility of using this class of service, in conjunction with the PINT work already undertaken, in order to provide a third flavour of service. Buller [Page 1] PSTN Initiated Services March, 1999 This Internet Draft deliberately does not to define the protocols for these kinds of services, although descriptions contained within it do use Session Initiation Protocol (SIP) terminology. The purpose of this Internet Draft is to ascertain the level of interest in pursuing this area of work. It is submitted with the goal of forming the basis of an Informational RFC and thereby further work on the standardisation of the provision of these kinds of services. Contents The contents of the rest of this document is as follows: Section 2 Acts as an introduction and defines the scope of this Internet Draft in relation to PINT. Section 3 Specifies the perceived requirements for any implementation of the group of services identified in Section 2. Section 4 Identifies an initial architecture to fulfill requirements of the class of service identified in this Internet Draft. Section 5 Describes an implementation of an example service (ICW) using this architecture. Section 6 Discusses initially identified security considerations which relate to the kind of service discussed in this Internet Draft. Section 7 Conclusions and identified further future study areas. Section 8 References and Glossary. Section 9 Acknowledges individuals providing assistance in the creation of this document. Section 10 Author's address. 2. Introduction In its charter, the description of the PINT working group states that it aims to address connection arrangements through which Internet applications can request and enrich PSTN services. Work to date has produced a proposal based on the use of the Session Buller [Page 2] PSTN Initiated Services March, 1999 Initiation Protocol (SIP) [2] and Session Description Protocol (SDP) [3] to achieve these objectives in respect of Internet initiation of PSTN services (as shown in Figure 1). ............................ : PINT area of interest : : : : PINT : : +----------+ REQUEST :+----------+ : | Internet |------------>:| PSTN | : +----------+ :| Services | : :+----------+ :..........................: Figure 1. As a result of this work the group has identified a need, and has begun discussions on, the possibility of using SIP and SDP in a similar manner in order to perform the reverse of this function i.e. initiating Internet services from the PSTN using some yet to be defined protocol (initially called TNIP, it being the reverse of PINT [4]) as shown in Figure 2. ............................ : : : +----------+ REQUEST :+----------+ : | Internet |<------------:| PSTN | : +----------+ TNIP :| Services | : :+----------+ :..........................: Figure 2. The service initially identified for this scenario is the Internet Call Waiting (ICW) Service, also known as Call Completion Internet Busy (CCIB). In this service, a PSTN user attempts to make a Plain Old Telephone Service (POTS) call in a traditional manner to another number. This second number is engaged, possibly because the person is presently connected to the Internet. The service should identify if this user is indeed connected, and if so, a message is sent over the Internet to inform this person about the call attempt. The user may then decide what action to take, dependent on what service options are provided by the service provider. This might be to drop the current Internet connection and take the call in the normal way, take the call as a Voice Over IP (VOIP) call, decline and give the calling party the option to leave a voice message or simply decline the call. Of course this is not the only service which could be deployed, other services, such as : o Remote Activation Using a telephone a user could request actions to be performed at some remote location. Buller [Page 3] PSTN Initiated Services March, 1999 o Remote Data Setting Using a telephone a user could create or modify information held on a remote machine. o Paging A paging service could send a text message to the user logged on to the Internet using voice to text conversion software. o Voice Messaging A voice message service, whereby a voice message could be taken and converted to an audio format which could be played on the users machine. o Voice to Email. could also be deployed. However, the real benefits of this class of service (PSTN activation) will be in its use, in conjunction with the work already undertaken within the PINT group, to provide a further completely new class of Intelligent Network (IN) 'like' services. This scenario is depicted in Figure 3 : ............................ : : : +----------+ REQUEST :+----------+ : | |<------------:| | : | Internet | :| PSTN | : | services | :| Services | : | |------------>:| | : +----------+ PINT :+----------+ : REQUEST : :..........................: Figure 3. The scenario of these kinds of services would be that a user uses the PSTN to initiate an Internet service. This Internet service could then either : Store information which could be used during an initation of an Internet Service at a some later time. or Initiate a PSTN service directly. A simple example of a service using both of these facets might be a number portability service. A user could use a telephone to specify the telephone number at their current location (perhaps using Calling Line Identity CLI) this is sent over the Internet (using the protocol which would come out of any future work) to a repository. Another user could then attempt to telephone the first user. This call is intercepted and the number called checked against the current known location by a request (using the protocol or profile which would come out of any future work) to ascertain the number registered by the first user. If the number is different, a PINT request could be Buller [Page 4] PSTN Initiated Services March, 1999 issued back to the PSTN to connect the call to the new number. For the purposes of this Internet Draft and identifying what kind of services are being disussed this Internet Draft identifies three groups of service which could be provided : 1. PINT Internet initiation of PSTN servives. 2. TNIP The reverse of PINT i.e. PSTN Initiation of Internet services and the protocol or profile which could provide these services. 3. SAINT Service Activation and the INTernet. An all encompassing classification which contains services provided by the previous two groups, plus any combination of these services, used to provide further services. Figure 4. provides a schematic of the different kinds of service. SAINT Service Activation on the INTernet | +----------------+----------------+ | | PINT TNIP PSTN INTernet Telephony iNitiation Interworking of IP services Figure 4. So, in the number portability serice described above, the service components would break down as follows : o The ability to call and set current location (telephone number) would be a TNIP flavour of SAINT which could be used in multiple services. o Similarly, the ability to look up the present location would also be a TNIP flavour of SAINT, as this would have been initiated via the PSTN. This also could be used in multiple services. o The ability to forward the call would be a PINT flavour of SAINT because this would be initiated from the Internet. Again, this functionality could be used in multiple services. o The whole combination of the above would be a SAINT service. Eventually, if further work in this area is undertaken, what is presently considered to be independent services within the PINT and TNIP class of service, might be seen more as functional components within a SAINT architecture of service provision. This Internet Draft will not consider the potential for PINT and TNIP combination kinds of SAINT services further. The mechanism for Buller [Page 5] PSTN Initiated Services March, 1999 providing these should 'fall out' of any work undertaken in the standardisation of PSTN initiated or TNIP services. 3. General Requirements For PSTN Initiation Of Internet Services This section aims to specify an initial set of requirements for any future work in the specification of a protocol, or implementation of, the group of PSTN initiated services identified in Section 2. o The profile should provide the service in a secure manner. o Any profile defined for PSTN initiation of services should reuse where possible existing IETF protocols. In particular, a profile for the PSTN initiation of services should be aligned with the PINT profile work undertaken to date. o The identification of any equipment (external to the Internet) within the specification of the protocol, or, service defined using this protocol SHOULD NOT be required. This would be in accordance with the PINT approach to date which places no requirements and identifies no specific equipment beyond the PINT gateway. o Provide the possibility for a service to be activated in a manner which is independent in both location of service and user. Section 5 describes one possible ICW implementation which allows a user to use the ICW service in a portable manner without that service being tied to a specific telephone number (and thereby service location). User (the caller) location can be considered to be location independent for this service. 4. Proposed Architecture The proposed architecture contains three main elements : 1) The user's machine. This contains a TNIP Server to receive INVITE and/ or NOTIFY messages. What action occurs next can be either predetermined by the service provider or dictated by the user themselves. 2) Information/ Service Repository. This could contain the service provider's services, service related information, subscriber related information or indeed accounting information. In Figure 5 this element is indicated as a single entity, where in fact, it may be comprised of several servers working together to provide the overall service. These functions receive INVITEs from the TNIP client, check where to send the message and perform any other service functionality. Next, the INVITE is forwarded to the TNIP server on the user's machine. These functions also receive REGISTRATION messages sent from the TNIP Server on the user's machine and maintain/store any relevent information contained in these messages. Buller [Page 6] PSTN Initiated Services March, 1999 3) TNIP Gateway. This 'could' receive service requests from the PSTN and formulates TNIP messages to be forwarded to the Information/ Service Repository or directly to the TNIP Server on the users machine. In so doing it acts as a TNIP client. A simplistic schematic of these elements is shown in Figure 5 below. ..................................................... : Scope of interest : : : : +------------------+ : : | Users Machine | : : | | : : | +--------------+ | : : | | TNIP Client/ | | : : | | Server | | : : | +--------------+ | : : +--------:---------+ : : | +------------------+ : : : | Information/ | : : | | Service | : : : | Repository | : : | | +--------------+ | : : :-..-..-..-..-..-..-..| TNIP Server | | : : | | +--------------+ | : : : | | : : | +------------------+ : : : : : | : : +--------------+ : : | TNIP | -..-..- TNIP Protocol : :...| Gateway |................................: | | +--------------+ | o | +--------------+ | PSTN | +--------------+ Figure 5. One thing to note about this architecture is that the Information/ Service Repository is not necessarily required. A User machine could handle a service itself if the TNIP client were to issue INVITEs and NOTIFYs to it directly. The function of the information/service repository itself could exist outside of the scope of interest demarcation indicated, as proposed in [5]. Maintaining the information/ service repository within the Internet Buller [Page 7] PSTN Initiated Services March, 1999 as indicated however, would permit interoperability with the work presently being undertaken within the IP Telephony (IPTEL) working group, specifically the proposed Call Processing Language [6]. Another point of note is that the TNIP boxes on the user machine and connected to the Gateway Function are indicated as Client/ Server. This is because the description of the implementation falls into two parts (see Section 5) and the behaviour of these TNIP boxes is more client or server like in each phase. 5. Implementation Scenarios This section describes how services might be implemented within the architecture described in the previous section. The order of flows is identified though the specific contents is not. As has been stated previously, this draft aims to ascertain the level of interest in this architecture and the services it could provide, prior to work on any actual specification of a protocol which will be required to support them. To reduce complexity the description is in two parts. First the user registers for the service. Secondly, a call attempt is made. 5.1. Service Registration Phase User Machine +-------------+ | TNIP Client | +-------------+ | ^ | | | | 1 | 3 | | | +--------------+ | | | Information | v | | Service | 2 ......... | Repository | .../ \... | | ../ \.. 1 | +--------+ | / \---------->| TNIP | | | Internet | | | Server | | \.. ../<----------| | | \... .../ 3 | +--------+ | \........./ +--------------+ Figure 6. 1. User submits a Registration message containing IP Address and any other information, such as in the case of ICW (if CLI is not available), their telephone number. 2. User details provided are registered. Buller [Page 8] PSTN Initiated Services March, 1999 3. Response message constructed and returned to registering Client. 5.1.1 Other issues As previously stated messages 1 and 3, and the function performed by 2 do not need to be located in what is called in this description the Information/ Service repository. These flows and the registration may be undertaken within the telephony network using IN [5]. The implemenation scenario described assumes that TNIP functionality has at some previous time been downloaded to the user's machine. This need not be the case. If it were required that a user could gain access to the Internet using any machine and still have access to these services, an implementation similar to that identified in Figure 7. and the following paragraph could be employed. User Machine +-------------+ |+-----------+| || Thin TNIP || || Server || |+-----------+| +---|-----^---+ | | 1 | 6 | | | v | ......... ...../ \..... ...../ \..... / \ | Internet | \..... ...../ | ^ \..... ...../ ^ | | \........./ | | | | ^ | | | 1 | 6 | 2 | 4 | 2 | 4 | v | | v v | +--------+ 5 +--------+ +--------+ | |<----| | | | | Web | | TNIP | | TNIP | | Server | 1 | Client | | Server | | |---->| | | | +--------+ +--------+ +--------+ | 3 | | v +----------+ | Database | +----------+ Figure 7. Buller [Page 9] PSTN Initiated Services March, 1999 1. The user goes to a service providers URL using a browser and specifies the information requested such as, in the case of ICW, telephone number. 2. The service provider constructs and issues a SIP registration message on behalf of the user. 3. User details provided are registered. 4. A response message is constructed and returned to registering Client. 5. Response message returned to service provider's Web Server. 6. A 'thin' TNIP User Server Agent is sent to the user machine. This can then be used in the service activation phase. The term 'thin' means that a full implementation of a TNIP server need not be required in order to handle specific requests. This is because of two main reasons. Firstly, the exact format of messages which may be sent by the service provider to offer this service is known. Secondly, only a subset of the full protocol need be required to provide the service. 5.2. Service Activation Phase User Machine +-------------+ | TNIP Server | 5 +-------------+ 4a ^ 6 | +--------------+ | v | Information | ......... | Service | 3 .../ \... | Repository | ../ \.. 2 | +--------+ | / \---------->| TNIP | | | Internet | | | Server | | \.. ../<----------| | | \... .../ 4a/4b | +--------+ | \........./ +--------------+ ^ | 2 | v 4b/ 6 +---------+ | TNIP | | Gateway | +---------+ ^ 1 | +---------+ | PSTN | |Equipment| +---------+ Figure 8. Buller [Page 10] PSTN Initiated Services March, 1999 1. A service activation request. For example an ICW service request is made after a call has been attempted and the PSTN has recognised that the number is engaged. An announcement could be played and a request sent from the Gateway to establish if the user is currently registered as wanting to receive INVITEs for a particular service. This will not be discussed further as it is outside the scope of this Internet Draft. 2. A TNIP invitation message is constructed and sent to the TNIP Server on the information/ service handler. 3. The TNIP server in the information/ service repository looks up the registration details of the user. Two things may then occur. If the user has registered details a TNIP invitation could be forwarded to the TNIP server on the user's machine (see 4a). In this case the information/ service repository performs as a redirection server or proxy. If the user has no registration information in the database (either because they have not registered or the registration has expired) a failure response is sent to the requesting TNIP client (see 4b). 4a. A TNIP invitation message is sent by the TNIP Server on the information/ service repository. This invitation contains a combination of information contained within the repository and information contained in the original request. 4b. A TNIP failure response is returned to the requesting TNIP client as no current regration information could be found. 5. User or service action to dictate what should happen as a result of the receipt the TNIP request. In ICW this might be to provide the user with the following options : Take telephony call Take VOIP call Send to voice mail Refuse connection 6. The user sends a response to the INVITE, a final timeout occurs or the client gives up. 5.2.1 Other issues As with the Service Registration Phase the flows to and from the information/ service repository and the actions it performs could be undertaken within the telephony network using IN [5]. The only flows in this scenario would be the invite 4a and the response 6. 6. Security Considerations Security issues are still an open issue within the PINT Internet Draft itself. It is expected that much of the security arrangements finally proposed by the PINT Internet Draft will be replicated within Buller [Page 11] PSTN Initiated Services March, 1999 any further work undertaken to provide the services identified in this Internet Draft. However, due to the nature of implementation of these services there are a number of security issues that need to be addressed. These are: o De-registration. o Claiming another number (somebody else's) by accident or design. 6.1. De-registration The de-registration problem would arise if a user did not de-register themselves before they finished using the Internet, likely to be a common occurrence e.g. users turning off their machines or modems without de-registering. It is expected that any implementation builds in a mechanism to handle this scenario. Authenticators could be used and passed in responses to the REGISTER messages sent to the TNIP service on the users machine. Alternatively, these authenticators could be placed directly in the TNIP server when it is initially downloaded. When the user logs off the Internet, without de-registering, there are three scenarios which could happen when an attempt is made to place a call to the number the user specified as their location : 1) The line is not busy, therefore place the call and remove any previously held registrations. 2) The line is busy on a voice call. An attempt to send a INVITE message from the Information/ Service Repository fails (as there would be no receiving client). Any previously held registration for this number is removed. 3) Another user (or the same user on a different Internet session) has registered for receipt of calls on this number. There are two solution possibilities : a) When the new registration is made the old is replaced immediately. or b) The new registration is kept until an Authenticator fails on the TNIP server of the new registrand when a call attempt is made. When the Authenticator fails the INVITE fails and the original registration can be removed and replaced with the new. The INVITE is then resent to the new registrand. 6.2. Claiming another number by accident or design. In this scenario a user may attempt to use ICW to claim notification on a line they have no right to, and possibly handle that call using VoIP, if the actual line is engaged. Consider the potential criminal Buller [Page 12] PSTN Initiated Services March, 1999 activities of claiming the telephone number of a Bank. This security issue is much more complex. The following options are suggested as possible solutions : 1) Only allow this kind of access from the user's own phone. 2) Provide functionality at the ISP to get the CLI and implement a SIP based mechanism to request this from the ISP. 3) Good accounting to track down offenders. 4) Only provide the option to drop the Internet connection and establish a POTS call on untrusted (e.g. not home) numbers. Normal Bank authentication procedeures could then be used. 7. Conclusions There is a perceived requirement for the provision of services which, whilst running over the Internet, would be initiated from the PSTN. This Internet Draft has proposed an initial attempt at defining an architecture for the provision of such services. This Internet Draft has also identified that these services may be used in conjunction with PINT services in order to provide a new kind of IN 'like' services with their logic operating within the Internet domain. It has also been identified that the architecture outlined in this Internet Draft permits service users to specify data which can then be used by services during execution. An extension to this approach, and a possible area of further work would be to investigate how the ability of users to define their services as proposed in [6] could be integrated with the initiation of a service from the PSTN. Much further work would be required in defining a TNIP style protocol or profile and identifying possible services for this protocol or profile. Identfying and specifying candidate services which use both the TNIP and PINT protocols, such as the portability service described earlier, would also require further work. Finally, neither PINT nor this proposal for a TNIP protocol address the issue of generalised/spontaneous notifications between the PSTN and IP domains. These notifications may be in the form service data or status information. Further work is required to identify how these notifications are sent, what handles these messages and how they are handled. It may be that PINT can be used to forward these messages to a TNIP server and vice versa. 8. References [1] Postel, J., "Instruction to RFC Authors", RFC 1543, October 1993. [2] Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., "SIP Session Initiation Protocol", RFC 2543, March 1999. Buller [Page 13] PSTN Initiated Services March, 1999 [3] Handley, M., Jacobson, V., "SDP Session Description Protocol" RFC 2327, April 1998. [4] Petrack, S., Conroy, L., "The PINT profile of SIP and SDP: a Protocol for IP access to Telephone Call Services", Internet Draft, November 1998. [5] Brusilowsky, A. et al, "A proposal for Internet Call Waiting Service using SIP. An implementation Report", Internet Draft, January 1999. [6] Lennox, J., Schulzrinne, H., "Call Processing Language Requirements", Internet Draft, July 1998. Glossary CCIB Call Completion Internet Busy ICW Internet Call Waiting IN Intelligent Network IP Intelligent Peripheral POTS Plain Old Telephone Service PSTN Public Switched Telephone Network SDP Session Description Protocol SIP Session Initiation Protocol VoIP Voice over IP (Internet Protocol) 9. Acknowledgments The author would like to acknowledge the following people. Lawrence Conroy for proof reading this document and pointing out the 'thin ice' in relation to this topic. I hope I have distributed my weight accordingly. Igor Faynberg for his encouragement to write this Internet Draft. Guenther Murphys in Munich for the Dunkles. 10. Author's Address Jim Buller Siemens Roke Manor Research Ltd., Roke Manor, Old Salisbury Lane, Romsey, Hampshire. SO51 0ZN. United Kingdom. Telephone: +44 (0)1794833666 Fax: +44 (0)1794833434 E-mail: jim.buller@roke.co.uk Buller [Page 14]