Internet Engineering Task Force PINT WG INTERNET-DRAFT Scott Petrack draft-ietf-pint-basics-00.txt VocalTec Communications Ltd. 21st Nov 1997 petrack@vocaltec.com Expires: 21st May 1997 IP Access to PSTN Services: Basic Service Requirements, Definitions, and Architecture Status of this Memo 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), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is not limited. This document is intended for the PSTN-Internet Interworking (PINT) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at pint@lists.research.bell-labs.com and/or the author at petrack@vocaltec.com Abstract This document specifies those PSTN services which will be accessible from the Internet via the PINT protocols. It defines these services in terms of a simple set of architectural elements and atomic services. It gives some concrete examples of these services, and indicates how to build the examples out of the presented atomic services. 1. Introduction The need to invoke and access a certain number of PSTN services from the Internet has been identified by many different groups (public and private network operators, call centre service providers, equipment vendors, etc.). Obviously, before any protocol or its details can be identified as suitable for the purpose, we must specify exactly which PSTN services are to made accessible. This draft defines some simple "service entities" and "atomic services" in terms of which we can specify those services. After defining these architectural elements, we verify that they are sufficient to define the example services that have been agreed upon as test cases within the PINT working group. The set of PSTN services that can be obtained from this architecture is what we call "the PINT Services." Finally, we state some security requirements for these new services. Internet Engineering Task Force (PINT WG) Scott Petrack draft-ietf-pint-basics-00.txt petrack@vocaltec.com Because the PINT working group is attended by members of non- intersecting language groups, it is important to define two key terms used within this draft: PSTN - "Public Switched Telephone Network." The term "PSTN" is used in this document interchangeably with "GSTN" (general switched telephone network) or "SCN" (switched circuit network). It refers to any switched voice and/or voice-band data Telephone Network of any type anywhere in the world. Thus it includes the ISDN and the GSM network, the various private PBX networks in existence, etc. (As such, it means something different from probably any other document which uses the term. PSTN is absolutely the wrong term, but unfortunately it appears the name of the working group. GINT, SINT, or TINT apparently didn't cut it). Internet - The term as used here refers to any collection of IP networks, including but not limited to the full Internet. It is useful to make explicit that the discussion here applies equally well to private intranet access to PINT services. The distinctions between "internet," "Internet," and "intranet" are very popular among some members of the PINT community, but are quite meaningless for the purposes of this draft. So the term "Internet" on the one hand and "PSTN" (or "GSTN") on the other are meant to be basically comparable. The first means here "some kind of IP network" and the second means "some kind of telephone network." 2. Background Initial discussions in PINT identified the following rather specific services as requiring access from the Internet: a. "request to call" - a request sent from an Client to a Server, which causes phone A to call phone B. b. "request to fax" - a request sent from a Client to a Server, which causes a fax to be sent to fax machine B. The content of the fax would be identified (possibly included) in the request. c. "voice access to web content" - a request sent from a Client to a Server, which causes a phone call to be made to phone B, and a certain "web content" to be read out to phone B. d. "request to conference call" - a request sent from a Client to a Server, which causes a conference call to be set up and a certain number of phones to ring, to invite the humans to join the conference. e. "request to transfer" - a request sent from a Client to a Server, which causes (at least) one of the phones to be disconnected from the call and (at least) one new phone to be joined to the call. f. "request to add new endpoint" - a request sent from a Client to a Server, which causes a new phone to be added to the call. In each request it should be possible to specify a time for the service to be invoked, and in each request it should be possible to specify a party C to whom a bill can be sent for the service (with some reasonable expectation that payment will result). It should be noted that within the current PINT list, there seems to be universal agreement really only about the first three services listed above (a,b, and c). There does seem to be rough consensus that the Internet Engineering Task Force (PINT WG) Scott Petrack draft-ietf-pint-basics-00.txt petrack@vocaltec.com latter three are within PINT's scope as well, however. The definitions of service elements and architecture outlined in this draft enable all six services listed above. If it is desired to exclude the latter three services, we shall see that this is very easy to do. It should also be noted that although much of the original PINT discussion was framed in terms of Intelligent Networking (IN), there is wide agreement that the above services make sense in almost any GSTN environment, regardless of the availability of IN. The rest of this draft describes a simple set of natural GSTN service elements that can be used to build the six services above, and which can be invoked via a request from an IP client to an IP host. 3. Service Entities for PINT Services There are five basic building blocks, which we call "service entities," from which PINT services can be built: Terminals, Calls, PINT clients, PINT Servers, and Billable Parties. They are defined as follows: 3.1 Terminals A Terminal is a GSTN terminal, such as phone, a fax machine, a voicemail machine, etc. Terminals have identifiers, which may be (but are not limited to) E.164 numbers. These identifiers may be globally unique, or only unique within some well defined context. A Terminal is in principle callable and can in principal make calls. 3.2 Calls A Call is a collection of GSTN resources (they can be internal to the GSTN and/or within Terminals). A simple point-to-point Call might consist of some resources within two Terminals and within the switches in between them. Calls have identifiers. For the moment the form of these identifiers is left unspecified, although it is required that it can be done in some globally consistent way. 3.3 PINT Clients and Servers A PINT Client sends a service request to a PINT Server and receives a service reply from the PINT Server. 3.4 Billable Party A Billable Party has an identifier and can accept or reject a Bill for a particular PINT service. The Bill is sent by a PINT Server to one or more Billable Party(ies). It is not yet decided if the the billing protocol is within the scope of PINT. But it is within the scope of PINT that a service request can contain a request that a Bill with some specified content can be sent to a specified Billable Party, and also that the service reply can contain secure notification of the acceptance or rejection of the bill. 4. Atomic Services and Compound Services The service entities together act to provide PINT services. A PINT service is the result of a service request from a PINT client to a PINT Server. The service requests can be for a single atomic service, or for a combination of atomic services, called a compound service. The atomic service requests are one of the following: Internet Engineering Task Force (PINT WG) Scott Petrack draft-ietf-pint-basics-00.txt petrack@vocaltec.com 4.4.1 Create a Call The Client requests the Server to create a Call. 4.4.2 Destroy a Call The Client requests the Server to tear down a Call. 4.4.3 Connect a Terminal to a Call The Client requests the Server to connect a specified Terminal to a specified Call. 4.4.4 Disconnect a Terminal to a Call The Client requests the Server to disconnect a specified Terminal from a specified Call. 4.4.5 Play some file data to a connected Terminal The Client requests the Server to play some file data of a given "type" into a Terminal that is connected to a particular Call. The file data might be included in the service request, or it might be merely identified (to be retrieved via some other means). Examples of types of file data might be type "fax" or type "text". Of course the precise meaning of "play" depends on the particular type of file data. 4.4.6 Check Status of a Request, Call, or Terminal The Client requests the Server to return information about the status of a particular Request, Call, or Terminal. The Check Status requests may ask for an immediate reply, or for the reply to be delayed until the relevant Request or Call is completed or an error occurs. 4.4.7 Send a Bill The Client requests the Server to send a bill to a Billable Party for one of the atomic or compound services. Each service request may be for service at a specified later time. In every case the request must contain the information about where to send the reply, whether or not the request is to be executed immediately or in the future. A compound service is built up by combining atomic services. There are three possibilities with respect to the time relations of the atomic services within the compound service: it may be that the atomic services are specified to run serially (so that one must complete before the next can begin), or it may be that only the start of each atomic service is specified to run serially (so that one must begin before the next can begin), or there may be no time relationship at all between the atomic services. Sending a Bill is one of the atomic services. This is how a PINT client asks the PINT Server to send a bill to a particular Billable Party. This may be the only service requested (in which case the request is one purely to send a bill to someone), or it may be one of several atomic services requested in the query (for example in a request to perform some service and send a bill for the service performed to a Billable Party). It is perfectly reasonable to send several requests for atomic billing services within a single service request. 5. Realisation of the Example Services of Section 2 It is not hard to define the particular example services of section 2 as compound services. For example, the point-to-point "request to call" service is simply a request to the PINT Server to create a Call, connect Terminals A and B to the Call, and send a bill to Billable Party C. But even in this simple case there is a point which requires comment: Internet Engineering Task Force (PINT WG) Scott Petrack draft-ietf-pint-basics-00.txt petrack@vocaltec.com The original example service definition of section 2 had "phone A call phone B." The service that we define in the previous paragraph is symmetric between phone A and phone B - these two Terminals are "connected to a Call." It is not clear who is calling whom. Of course, the service required can be made more precise by specifying that the compound service is built up from the atomic elements by executing them serially: first the Call is created, then phone A is connected, then phone B is connected, then a bill is sent. (Perhaps various audio prompt file data are played into phones A and/or B at the appropriate times). During some previous PINT discussions, a distinction was drawn between "third party service control" and "sending an invitation to a proxy server acting on behalf of a Terminal." The architecture presented here is really an example of "third party service control" - the PINT Server is connecting the two Terminals A and B, rather than a request being sent to a proxy server for Terminal A to call Terminal B. It seems that in order to include all the example scenarios in a single framework, it is more natural to think in terms of third party service control. In practise, the difference is more pedantic than really important. Realising the other examples of section 2 as compound services is equally straightforward. 6. Security Considerations and Requirements There are two or more different IP hosts involved in each invocation of a PINT request: a PINT client, a PINT Server, and zero or more Billable Parties. It is required that each of these hosts can authenticate itself to another, independently of the others. It is required that each message exchange can be private and/or non-repudiatable. The process by which two entities exchange keys or secrets in order to ensure authentication, privacy, and non-repudiation, are beyond the scope of the PINT service architecture or protocols. 7. Acknowledgements The author would like to acknowledge input from the PINT mailing list as a major source of ideas which appear in this draft. The archive of the PINT mailing list can be found at the following URL: http://www.bell- labs.com/mailing-lists/pint/. In particular, postings of Claudio Catania, Igor Faynberg, Dave Oran, Lawrence Conroy, Wilhelm Wimmreuter particularly informed parts of the discussion. Internet Engineering Task Force PINT WG INTERNET-DRAFT Scott Petrack draft-ietf-pint-basics-00.txt VocalTec Communications Ltd. 21st Nov 1997 petrack@vocaltec.com Expires: 21st May 1997