PINT Working Group L. Conroy INTERNET-DRAFT Siemens Roke Manor Research Category: Informational J. Buller Expires: January 2001 Unisphere Solutions A list of possible PINT functions 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.'' 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. 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 (2000). All rights reserved. Abstract This Internet Draft is one of a pair written at the request of one of the SPIRITS Working Group co-chairs in order to elicit discussion on what extended functionality SPIRITS may be used to provide; the PINT work has similar requirements for a definition of the building blocks that might be used in future services (and so need to be supported by the protocol). This note provides the "mirror image" of the associated SPIRITS draft, listing functional building blocks that may be executed in response to future PINT protocol requests. Conroy, Buller [Page 1] July, 2000 Contents of the rest of this document are as follows: Section 1...................................................... 2 Introduction Section 2...................................................... 2 PINT functions Section 3...................................................... 5 Security Section 4...................................................... 5 Summary Section 5...................................................... 6 References Section 6...................................................... 6 Authors' addresses 1. Introduction This document lists 'possible' extensions of functionality ("building blocks") to PINT to aid discussion. It should be read in conjunction with the equivalent SPIRITS document ("draft-conroy-spirits-act-00.txt"). It is expected that future extensions to PINT services will use more of the features available within the PSTN/IN, and so these functions might be expected to be exposed to requesting clients; this will almost certainly be reflected in future use of the PINT Service Protocol. 2. PINT functions 1) Registrations/ Deregistrations of an PSTN entity to the Internet entity (getting trusted entities 'known' to the Internet entity) This is done already in PINT Service Protocol, using REGISTER messages. 2) Registration of available services in the PSTN domain This is done already in the PINT Service Protocol (PSP). Note that in PSP, this is carried out at the same time as registering an entity; both are requested in a single REGISTER message. The entity registers not only the service (the user-part) but also the address to which such requests should be sent (the host-part). 3) Request service handling by entity in PSTN domain This is part of the normal PINT request processing, and as such is defined in PSP already. Conroy, Buller [Page 2] July, 2000 4) Service Handling terminated by entity in PSTN domain and handed back to entity in Internet domain for resumption. PSTN domain Service handler takes no further interest in service This appears to be the normal PINT service processing. However, it may be extended as a function that has the effect of "handing off" responsibility for processing a PSTN service to the Internet. Whilst it is not clear quite how such an arrangement could be arranged in practice, it is nevertheless a pattern that we may want to consider. 5) Service handling passed back to entity in Internet domain. However, an interest (perhaps implemented as some kind of monitoring function) is maintained by service handler in the PSTN domain relating to 'this' instance of service This potential function has the effect of "handing off" responsibility for processing a PSTN service call to the Internet, whilst allowing the PSTN service processing to "maintain an interest" in the disposition of the service processing (possibly by the Internet entity returning status information to the PSTN entity. Again, this relationship is not covered in the existing PINT architecture, but could be appropriate for some complex services. For example, a PINT executive system may have been asked to make a call leg from a gateway onwards to a PSTN end user (see next function, for example), with the Internet entity continuing execution of the overall service by joining a different call leg from an Internet user to that call leg within the gateway. 6) Entity in the Internet domain requests an initial PSTN call This building block can be seen as a re-statement of the existing PINT service requests. 7) Entity in the Internet requests a PSTN call leg This is a building block that is a primitive that might be viewed as part of the implementation of a PINT Click-to-Dial service. It differs in that, as only one call leg is requested, and the PINT model implies a third-party call control model is used in the execution of the service, there will have to be a subsequent "join leg" primitive action. 8) Entity in the Internet requests deletion of a PSTN call leg To ensure widest possible implementation, the existing PINT architecture does not assume that any existing Service call can be terminated on request from an Internet entity. However, it is at least possible that PINT Executive Systems that implement CS-2 call leg manipulation actions can process such requests. 9) Entity in the Internet requests a connection of 2 or more PSTN call legs This function differs from the existing PINT Click-to-Dial service in that there may be more than two call legs that are to be connected (or joined), the way in which the call legs are referred to may differ, and that this would normally consist of joining a set of call legs that have been created previously using a number of separate "add leg" primitives. Conroy, Buller [Page 3] July, 2000 10) Entity in the Internet domain requests transfer of a PSTN call leg At present, PINT does not define a service to transfer a call leg from one association to another. However, this is a useful service, and so should be considered. 11) Entity in Internet domain requests a Hold/Resume for PSTN-based call leg The existing PINT services do not define a mechanism to change a service call once in place. This function is another primitive that would let an Internet entity to manipulate an existing service call, and so extend more features of the I.N. service processing "upwards". 12) Event Notification requests sent from Internet to PSTN domain This function is defined already within the PINT Service Protocol (PSP), using the Subscribe method. However, its use might be extended to cover a request for status on a wider range of entities than a PINT service. 13) Event Notification responses sent from PSTN domain to Internet domain This function is defined already within PSP (using the Notify method). 14) Event Notification Session Termination This function is defined already within PSP (in the Unsubscribe method). 15) The ability to request an entity in the PSTN domain to Output tones or play announcements or messages As before, this primitive extends commands that exist in the PSTN "upwards" to the Internet. This function would allow a PSTN call leg associated with an Intelligent Peripheral to have tones or announcements (or voice prompts) played out to it. 16) The ability for an entity in the Internet domain to collect information from the PSTN domain (e.g. DTMF) This primitive reflects the "collect" command that exists within the Intelligent Network. In the PINT case, the collected digits would be returned to the Internet entity that made the service primitive request. 17) The ability to set service data and user data in the PSTN domain from the Internet domain This is a major function indeed. It might enable I.N. triggers to be set or PSTN customer service status (i.e. whether or not a PSTN user is subscribed to a service) to be changed, and might also allow current PSTN status to be returned. In its latter guise it is similar to the Subscribe/Notify mechanism that exists within PSP already, but in this case there is no prior PINT service on which status notifications are to be returned. The details of this primitive warrant further discussion. Conroy, Buller [Page 4] July, 2000 3. Security Security issues are for further discussion. This document is only intended to provide the basis for such discussion. 4. Summary This note has described some functional building blocks for PINT services. The functional building blocks were: * Registrations/ Deregistrations of an PSTN entity to the Internet entity (getting trusted entities 'known' to the Internet entity) * Registration of available services in the PSTN domain * Request service handling by entity in PSTN domain * Service Handling terminated by entity in PSTN domain and handed back to entity in Internet domain for resumption. PSTN domain Service handler takes no further interest in service * Service handling passed back to entity in Internet domain. However, an interest (perhaps implemented as some kind of monitoring function) is maintained by service handler in the PSTN domain relating to 'this' instance of service * Entity in the Internet domain requests an initial PSTN call * Entity in the Internet requests a PSTN call leg * Entity in the Internet requests deletion of a PSTN call leg * Entity in the Internet requests a connection of 2 or more PSTN call legs * Entity in the Internet domain requests transfer of a PSTN call leg * Entity in Internet domain requests a Hold/Resume for PSTN-based call leg * Event Notification requests sent from Internet domain to PSTN domain * Event Notification responses sent from PSTN domain to Internet domain * Event Notification session termination * The ability to request an entity in the PSTN domain to Output tones or play announcements or messages Conroy, Buller [Page 5] July, 2000 * The ability for an entity in the Internet domain to collect information from the PSTN domain (e.g. DTMF) * The ability to set service data and user data in the PSTN domain from the Internet domain 5. References [1] Postel, J., "Instruction to RFC Authors", RFC 1543, October 1993. [2] Petrack, S., Conroy, L., "The PINT Service Protocol: Extensions to SIP and SDP for IP access to Telephone Call Services", RFC 2848, June 2000. 6. Authors' Addresses Lawrence Conroy Siemens Roke Manor Research Roke Manor Old Salisbury Lane Romsey, Hampshire U.K. SO51 0ZN Phone: +44 (1794) 833666 EMail: lwc@roke.co.uk Jim Buller Unisphere Solutions, 900 Broken Sound Parkway, B12S Boca Raton, FL 33487. USA Phone: +1 561 923 3132 EMail: jBuller@unispheresolutions.com Conroy, Buller [Page 6]