SPIRITS Working Group L. Conroy INTERNET-DRAFT Siemens Roke Manor Research Category: Informational J. Buller Expires: January 2001 Unisphere Solutions A list of possible SPIRITS 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 has been 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. It has been requested that mapping to any specific protocol is not undertaken at this juncture. As such, only 'possible' functionality is identified and no mapping to existing protocol methods is given. This document is only intended to provide a basis for discussion and would be expected to form one aspect of the requirements for SPIRITS. As such the terminology used is deliberately and (we hope) suitably ambiguous. Conroy, Buller [Page 1] July, 2000 Contents of the rest of this document are as follows: Section 1:Introduction......................................... 2 Section 2:Classification of actions............................ 3 Section 3:SPIRITS functions.................................... 3 Section 4:Security............................................. 6 Section 5:Summary.............................................. 7 Section 6:References and Glossary.............................. 8 Section 7:Authors' addresses................................... 8 1. Introduction Requirements for an application-specific transport protocol can be captured from three main aspects. These are: * The architecture in which it will operate, * The behaviour expected of the communicating entities and so the pattern of interaction they have, * The information exchanged that is germane to (or qualifies) behaviour engendered by the communication This last aspect can be re-phrased as * The information that is available to the initiating entity that can be passed to the executive or recipient entity Summarising these points as questions: - who communicates? - what are they to do? - what do they need to be told in order to do it? or - what information is available at the sender to tell the recipient? The architectural drafts submitted for the SPIRITS work have so far concentrated on the first question and, in its second form, the last question. Rather than focus on the sender of requests, this note considers the kind of behaviours that the recipient of the request might be asked to perform. Both approaches can be combined to qualify the requirements that the protocol will need to cover; both the state available at the sender AND the behaviours expected of the recipient will have to be taken into account. From the charter (and the ICW service descriptions), the architecture is one in which a PSTN-based system requests actions to be carried out by an Internet-based entity. The PSTN-based system is further qualified as one that maintains call state, and can carry out some internal actions on a transition in this call state. Conroy, Buller [Page 2] July, 2000 The result of these internal actions is that a request for service is constructed and sent to the Internet entity, and that this entity will inform the requestor of either the result of this action, or (at least) that this request has been received and is to be processed. In other drafts, the information available in the PSTN at a given call state is being considered. For example, this could be the data available to an SCF on receiving a DP message from an SSF. In this case, if a request for action in the Internet were to be generated as a result of the SCF receiving the DP message, then there is a limit to the information that could in turn be used to generate the request. This gives a bound for the actions that might be expected of the Internet entity; it reflects the statement that, if you can't tell it how to do something because you don't have the information, then the recipient of a request can't be expected to do it. This note, however, lists the kind of "things that I want you to do". There is also a companion note that lists the kind of things that could be done in the PINT domain. 2. Classification of actions The functions that might be performed by a SPIRITS server in response to request from a PSTN entity are classified in the next section into five sets. This is only an initial view, and is put as a spur to discussion only. The sets are: * Server/Service Registration * Request/Service Processing * VoIP Call Leg Manipulation * SPIRITS Service Monitoring * Special Resource Functions 3. SPIRITS functions 3.1. Server and Service Registration 1) Registrations/ Deregistrations of an Internet entity to the PSTN entity (getting trusted entities 'known' to the PSTN entity). This registration asserts that the registrant is an entity in the SPIRITS architecture. It is most likely to be used to identity a SPIRITS server (i.e. it states that SPIRITS requests may be sent to this entity). 2) Registration of available services in the Internet domain. This registration asserts that this function can be carried out. In practice, the ability to execute this function will be registered by some entity. It seems sensible for the Registrar to assume that the entity making this registration can execute the function, so this registration serves a dual purpose; both to register this function as one that can be performed, AND to register the entity as one that can perform it. Conroy, Buller [Page 3] July, 2000 3.2 Request/Service Processing 3) PSTN requests service handling by entity in Internet domain. This is a request for an action to be performed - "please do ". There are several "flavours" of what happens in response: 4) Service Handling terminated by entity in Internet domain and handed back to entity in PSTN domain for resumption. Internet domain Service handler takes no further interest in service. This variant states "please do as part of my processing". This implication is that the SPIRITS server is carrying out a sub-function and can forget about it afterwards. 5) Service handling passed back to entity in PSTN domain. However, an interest (perhaps implemented as some kind of monitoring function) is maintained by service handler in the Internet domain relating to 'this' instance of service. This differs from the previous function in that the SPIRITS server is informed on the disposition of the PSTN action of which it's processing is a part. This could be used, for example, to allow post-service synchronisation of state between the Internet and the PSTN. 3.3. VoIP Call leg Manipulation Whilst the PINT services can result in a PSTN-based service call, it seems at least possible that SPIRITS services might result in a pure "VoIP" call. This might be executed "behind" the SPIRITS server using, for example, SIP third-party call control actions. The functions described here, however, are the *service requests* to a SPIRITS server, not the way in which that service is executed. 6) Entity in the PSTN domain requests an initial VoIP call This is a request for a VoIP call to be placed between two parties on the Internet. It is, in effect, a "macro-function" in that it could be constructed from two of these subsequent functions. It is likely to be widely used, however, so it may be convenient to consider it as a single command (i.e. one that can be carried out as a result of a single request). 7) Entity in the PSTN domain requests a VoIP call leg This request asks that a VoIP call leg be extended to an entity in the Internet. An open question for the following functions is how call legs are identified. If the call leg has been created in response to an earlier SPIRITS service request, then the identity of the leg to be removed may be able to use a reference to that earlier service request. The detail of the way in which the call leg would be identified is for further discussion, as this service may operate "in the context" of an earlier service. Conroy, Buller [Page 4] July, 2000 It is unclear whether or not the "call control" call leg identity will be known to the PSTN entity that made the earlier request, and so whether or not this can be used somehow to refer to the leg(s) in question. 8) Entity in the PSTN domain requests deletion of a VoIP call leg This request asks that a previously created call leg that exists to an entity in the Internet be removed. 9) Entity in the PSTN domains requests a connection of 2 or more VoIP call legs This requests that two or more call legs that have been previously created should be joined to allow bi-directional media exchange. 10) Entity in the PSTN domain requests a transfer of a VoIP call leg This request asks that the existing association between a call leg and another be dissolved, and that a new association with a different call leg be created. 11) Entity in PSTN domain requests a Hold/Resume for VoIP call leg There are two request types here. In the first, this request asks that a call leg that was in an existing association with another be suspended. In the second, it asks that the association with another call leg that was suspended be reinstated. 3.4. SPIRITS Service Monitoring These functions are the converse of the PINT Subscribe/Notify/Unsubscribe mechanism. 12) Event Notification requests sent from PSTN domain to Internet domain. This is the converse of the PINT Subscribe request. It asks that a monitoring session be instated so that the status of a SPIRITS service (or events within that service) be reported to the PSTN entity. 13) Event Notification responses sent from Internet domain to PSTN domain. This is the converse of the PINT Notify message. It reports on the status or events within a prior SPIRITS service, for which a monitoring relationship with the PSTN entity exists. 14) Event Notification session termination This is the converse of the PINT Unsubscribe request. It is expected that this request is symmetrical, in that it could be sent either from the SPIRITS server to the PSTN entity that has an existing monitoring relationship, or from that PSTN entity to the SPIRITS server to inform it that the monitoring session is no longer required. Conroy, Buller [Page 5] July, 2000 3.5. Special Resource Functions 15) The ability to request an entity in the Internet domain to Output tones or play announcements or messages. This is the Internet equivalent of the I.N. System "play announcement" command to an Intelligent Peripheral. It assumes that there is a reference available at the SPIRITS server to the call leg to be associated with the entity that is to make the announcement; this may be passed from the PSTN entity if it is known from a prior service, or the call leg may be implicit from a reference to a prior service that created the call leg. 16) The ability for an entity in the PSTN domain to collect information from the Internet domain. This is the Internet equivalent of the "collect" command to an Intelligent Peripheral. In the SPIRITS case, however, the application is *much* wider. For example, in the ICW service, the potential terminating user may be asked whether or not they want to accept an incoming call. The way in which they are asked could be via some instant messaging scheme; thus this could cover not only collection of information from an existing call leg within the Internet but also using some other scheme from the potential B party (i.e. where a VoIP call leg has not yet been created). 17) The ability to set service data and user data in the Internet domain from the PSTN domain. This is a fairly wide building block. It can be used, for example, to change the behaviour of Internet entities in response to future events (the equivalent of the "set trigger" action within the PSTN), to change registration/subscribed services state (the equivalent of the PSTN "set service mark" action), to add or change some service related data stored within the Internet. This last might be used, for example, to create an association between an Internet address and a PSTN identifier such as a PSTN address. The kind of detailed action that might be performed is limited by the information available within the PSTN. Refining the scope for this function is for future discussion. 4. Security Security issues are for further discussion. This document is only intended to provide the basis for such discussion. It is expected that any action to be performed be executed only if the recipient of a request is sure that the requestor has a right to make a request, and that the server itself has a right to carry it out. Where "subsequent actions" are to be carried out in the context of an earlier service, then there is a further security implication that the entity requesting this further service has the right to ask for a particular service context to be manipulated (e.g. for a given service call leg to be changed). Conroy, Buller [Page 6] July, 2000 Equally, where monitoring is to be provided, the privacy implications of such actions on the person engaged in a call leg (and any others associated with that call leg) must be considered. 5. Summary This note has described some building blocks for SPIRITS services. The functional building blocks were: * Registrations/ Deregistrations of an Internet entity to the PSTN entity (getting trusted entities 'known' to the PSTN entity) * Registration of available services in the Internet domain * PSTN requests service handling by entity in Internet domain * Service Handling terminated by entity in Internet domain and handed back to entity in PSTN domain for resumption. Internet domain Service handler takes no further interest in service * Service handling passed back to entity in PSTN domain. However, an interest (perhaps implemented as some kind of monitoring function) is maintained by service handler in the Internet domain relating to 'this' instance of service * Entity in the PSTN domain requests an initial VoIP call * Entity in the PSTN domain requests a VoIP call leg * Entity in the PSTN domain requests deletion of a VoIP call leg * Entity in the PSTN domains requests a connection of 2 or more VoIP call legs * Entity in the PSTN domain requests a transfer of a VoIP call leg * Entity in PSTN domain requests a Hold/Resume for VoIP call leg * Event Notification requests sent from PSTN domain to Internet domain * Event Notification responses sent from Internet domain to PSTN domain * Event Notification session termination * The ability to request an entity in the Internet domain to Output tones or play announcements or messages * The ability for an entity in the PSTN domain to collect information from the Internet domain Conroy, Buller [Page 7] July, 2000 * The ability to set service data and user data in the Internet domain from the PSTN domain 6. 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. Glossary SCF - Service Control Function SSF - Service Switching Function DP - Decision Point PSTN - Public Switched Telecommunications Network ICW - Internet Call Waiting 7. 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 8]