PINT Working Group J. Buller INTERNET-DRAFT Unisphere Solutions Category: Informational Expires: December 2000 A proposal for the provisioning of Call Completion Internet Busy using PINT and SPIRITS 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 (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 and SPIRITS working group. This Internet Draft describes an implementation architecture for co-operative services initiated from either the PSTN or Internet domains. It further describes how this architecture may be used in provision of a Call Completion Internet Busy (CCIB) aka Internet Call Waiting (ICW) service. Buller [Page 1] CCIB (PINT & SPIRITS) December, 2000 This Internet Draft deliberately does not define the protocols for these kinds of services, although descriptions contained within it do use Session Initiation Protocol (SIP) terminology. Contents The contents of the rest of this document is as follows: Section 2 Acts as an introduction providing a high level description of the ICW/ CCIB service and the difference between PINT and SPIRITS. Section 3 Specifies the general requirements for implementations of the service identified in Section 2. Section 4 Identifies and discusses the general architectural considerations in provisioning enhanced co-operative services such as CCIB/ ICW. It then proposes the architectural elements required to perform the CCIB/ ICW service, described in the remainder of this Internet Draft. Section 5 Describes the implementation scenario of an CCIB/ ICW service using these architectural elements. Section 6 Discusses initially identified security considerations which relate to this implementation of the CCIB/ ICW service. Section 7 Conclusions. Section 8 References and Glossary. Section 9 Acknowledges individuals providing assistance in the creation of this Internet Draft. Section 10 Author's address. 2. Introduction The primary considered service to date, with regard to the efforts of the SPIRITS working group, is that of Internet Call Waiting ICW (aka Call Completion Internet Busy, or CCIB). The CCIB service allows users who are logged onto the Internet (using for example, a dial up account) to determine the completion actions for telephony calls attempted to the telephone number that they are presently using for this connection. Examples of these 'completion actions' might be : Buller [Page 2] CCIB (PINT & SPIRITS) December, 2000 o Refuse the call. o Forward the call to Voice Mail. o Forward the call to another number. o Drop the Internet connection and take the telephony call over the same line. 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 end device. This document briefly describes how implementation of such a service could be undertaken using both PINT and some other protocol (possibly aligned with the SPIRITS architecture). Both PINT and SPIRITS are intended to provide mechanisms for requests (or initiation) of service between the Internet and PSTN domains, and vice versa. Requests (initiations) from the Internet to the PSTN and responses to these requests is the PINT case. Requests from the PSTN to the Internet domain and responses to these requests is the SPIRITS case. This is shown more clearly in Figure 1. ................................ : IETF PINT/SPIRITS WG Domain : : : : +----------+ :+----------+ : | Internet | :| PSTN | : | Domain |+--------------+:| Domain | : | Services || PINT |:| Services | : | || |:| | : | A || request |:| P | : | P |>>>>>>>>>>>>>>>>:| S | : | P || |:| T | : | L || response |:| N | : | I |<<<<<<<<<<<<<<<<:| | : | C || |:| | : | A |+--------------+:| S | : | T | :| E | : | I | :| R | : | O |+--------------+:| V | : | N || SPIRITS |:| I | : | || |:| C | : | S || request |:| E | : | E |<<<<<<<<<<<<<<<<:| S | : | R || |:| | : | V || response |:| e.g. | : | E |>>>>>>>>>>>>>>>>:| IN or | : | R || |:| Soft | : | S |+--------------+:| Switch | : | | :| | : +----------+ :+----------+ ................................ Figure 1. PINT and SPIRITS bridging the PSTN/ Internet domains Buller [Page 3] CCIB (PINT & SPIRITS) December, 2000 3. General Requirements This section attempts to specify an initial set of requirements and service characteristics for an implementation of CCIB using the PINT and SPIRITS paradigms: o Use of the service MUST be capable of being undertaken in a secure manner. o Use of this service should be non repudiable. o The described implementation should not be dependent in ANY way on specific technology being deployed outside of the Internet domain. 4. Proposed Architecture This section initially discusses the CCIB service and architectural considerations and implications. Next, the proposed architecture for the CCIB service which uses PINT and SPIRITS is outlined. 4.1. General architectural and service considerations and implications The implementation detailed in this Internet Draft allows subscibers to register for this service. This registration could be forwarded to the PSTN domain using the PINT protocol. Such a registration may be undertaken each time a subscriber connects to the Internet and wishes to receive (SPIRITS like) requests. Specific details of what and how the PSTN domain may implement certain aspects of this service are considered outside the scope of this Internet Draft. As such, only generalised functional descriptions are provided and no specific recommendation or suggestions are proffered. Possible implementations might be that the PSTN domain could : o Dynamically set flags (service marks) in the switch relating to the subscribers line. This could indicate that call attempts to this number (for the duration of the current call) will result in the initiation of a SPIRITS service. o An IN system could be used to handle call attempts to busy lines over which a subscriber is engaged in an Internet session. Indeed, it is entirely possible in some implementations (say, a Soft Switch providing Internet Offload) that no registration phase will be required. This scenario is not discussed further as this paper deals with the co-operation of PINT/ SPIRITS to provide enhanced services. In implementatations where explicit subscriber registration is deemed to be required (such as the one detailed in section 5) registration storage can be undertaken in several locations in either the Internet or PSTN domains. This data can either be : o located in the Internet domain and referenced directly by a ICW/ CCIB SPIRITS client (also in the Internet domain) once it has Buller [Page 4] CCIB (PINT & SPIRITS) December, 2000 received a request from the PSTN (see note below). or o located in the PSTN domain and referenced by some entity within this domain that then issues the request to the CCIB/ICW SPIRITS client in the Internet domain (see note below). In some impleme- ntations this request may require some form of resolution within the Internet domain to map the request to the current IP address of the subscriber. Note! the request initiated within the PSTN domain is itself NOT a SPIRITS request. This interface/ invocation mechanism is considered (by the author) to be out of scope, very likely to be implementation specific and most probably proprietary in nature. Differentiation of this interface from that provided by the SPIRITS protocol has been the source of some apparent confusion. However, if we take a closer look at the PSTN interface identified in Figure 1. and add some of the functional components, originally specified in the PINT protocol, and then apply a similar paradigm to SPIRITS the situation becomes clearer. ........................................ : IETF PINT/SPIRITS WG's Domain : : +-------------+ +----------------------------+ : | Internet | : PSTN/IN/Soft Switch | : | Services | +-------:--------+ Services | : | | PINT | PINT : | | : | | | G/W : | +-----------+ | : | +-----------| request |-------:-------+| | | | : | | |>>>>>>>>>>>>>| : |>>>>>>| | | : | | PINT | | PINT : SoP || SoP | Executive | | : | | CLIENT | response |SERVER : CLIENT|| 1 | System | | : | | |<<<<<<<<<<<<<| : |<<<<<<| | | : | +-----------| |-------:-------+| +-----------+ | : | /\ | +-------:--------+ /\ | : | Co-operation| : Co-operation | : | to provide | +-------:--------+ to provide | : | services | SPIRITS |SPIRITS: | services | : | \/ | |G/W : | \/ | : | +-----------| request |-------:-------+| +-----------+ | : | | |<<<<<<<<<<<<<| : |<<<<<<| | | : | | SPIRITS | |SPIRITS: SoP || SoP | Initiative| | : | | SERVER | response |CLIENT : SERVER|| 2 | System | | : | | |>>>>>>>>>>>>>| : |>>>>>>| | | : | +------.----| |-------:-------+| +-----------+ | : | ^ . | +-------:--------+ | : | . . | : | : +-------------+ :+---------------------------+ : : G/W - Gateway ........................................ SoPx - Some other Protocol Figure 2. Architectectural differentiation between the PINT and SPIRITS protocols and PSTN/IN interface So taking the above PSTN interface architecture into account and referencing back to where registration information may be stored; it Buller [Page 5] CCIB (PINT & SPIRITS) December, 2000 can be seen that the SoP interface itself will vary dependent on the implemenation decisions made. However, as previously stated, the SoP interface is considered to be out of scope of this Internet Draft. Upon receipt of an initiation request from some entity in the PSTN domain, the request is passed to the SPIRITS client in the SPIRITS gateway for formulation of SPIRITS message(s). These messages may be used to gain further information from entities in the Internet domain or to initiate/ request SPIRITS services directly. 4.2. Proposed Architecture This section identifies and describes the architectural entities identified in Figure 1 and how these relate to the provision of 'one' possible implementation of a CCIB service discussed in more detail in section 5 of this document. Various implementations may locate this functionality in different places or domains (PSTN or Internet). Some entities may not be required in other possible implementations. The entities within this proposed implementation are : PSTN An entity in the PSTN domain (e.g. IN or Soft Switch) initiates a request for service from this domain to the Internet domain. As previously discussed (in Section 4.1.) this does not mean that it directly passes SPIRITS requests. Instead requests are issued to the SPIRITS gateway where the SPIRITS client constructs and issues SPIRITS requests. User equipment In the implementation detailed in this document the user connects to Internet using a dial up account from equipment suitable for such connectivity. User equipment will have a small SPIRITS server for receiving SPIRITS requests and 'possibly' a PINT Client for registration and initiation of PINT services. These entities may have been previously downloaded or may be downloaded each time a subscriber registers that they are connected and wish to be able to use PINT and SPIRITS services. Web Server Provides a mechanism for subscribers to register for receipt of SPIRITS messages. SPIRITS client Contained within the SPIRITS gateway (see Figure 2), it receives initiating requests from the PSTN and formulates them into SPIRITS requests. SPIRITS server Receives and handles SPIRITS requests. As previously stated, this server could either be initially downloaded and used after each subsequent registration, or, downloaded each time as part of the registration process. Buller [Page 6] CCIB (PINT & SPIRITS) December, 2000 Subscriber data store Maintains subscriber details and registration requests. 5. Implementation Scenario Figures 3 and 4 briefly detail an implementation for provisioning the Call Completion Internet Busy (CCIB) service. These figures identify the objects and the sequence of flows required and are split into two for clarity. The first provides details of how registration for use of the service is made. The second details how the user is contacted after a call attempt has been made, and how their choice, as to how to handle the call, is then relayed to the initiative system. 5.1 Service Registration Phase There are at least two mechanisms (excluding the Soft Switch Internet Handoff scenario indentified in Section 4.1), each with a variety of flavours, in which the registration and setup for this service may occur. Each of these depends on the various business models which different vendors might wish to implement: 1) The service may be implemented by use of an explicit binding to a telephony subscriber's known (billable) number. The customer may then either register or subscribe to the service when they connect to the Internet. This registration could be held in the PSTN domain where receipt of a call attempt to a busy telephone number may directly result in a service request, or result in a check of a data store of current registrands in the PSTN domain before the service is requested. Alternatively, the registration information may be held in the Internet domain, and the PSTN system may query this store, and activate the service, when the line is found to be engaged. This type of implementation is inherently more secure than the next option due to the explicit binding to a telephone number. Mechanisms can more easily be provided to require registrations from this line for the subscriber. 2) The second scenario could allow a subscriber to register at whatever telephone number they happen to be using for their dial up connection. Once on-line they would register to the service. This registration could contain the currently used telephone number though this provides further security risks (e.g. wrong number specification by fault or design). This proposal could allow subscribers to register in a portable fashion from any number. This might be less satisfactory than 1 (above) in terms of phone number security i.e. in tying such service provision to a number by what an ISP clients 'says'. However, some implementation of Calling Line Identitity (CLI) could be used by the ISP to obtain this number directly. It is most likely that there would be Buller [Page 7] CCIB (PINT & SPIRITS) December, 2000 a requirement for interworking and/ or Service Level Agreements (SLA) between the ISP and telephony operator in order to secure such a service. Such interworking is outside the scope of this Internet Draft. The maintenance of the subscribers registration could follow the same lines as those discussed in 1) above. This option is inherently less secure than that suggested in 1) above. +----------------+ | User Equipment | | | | +-------+ | | | Modem | | ()-() | +-------+ |--- /^\ +----------------+ --- | | ^ | | | 1| 2| 7| | | | v | | +----+ | | |ISP/| | | |RAS | v | +----+....... ...../ \..... ....../ \...... / \ | Internet | \...... ....../ | ^ \..... ...../ | ^ | | \........../ | | | | ^ | | | | | | | | | 2| 7| 3| 5| 3| 5| v | | v v | +--------+ 6 +---------+ +-----------+ | Web |<----| PINT | | PINT | | Server |---->| Client | | Server | +--------+ 2 +---------+ +-----------+ ^ | | v +-----------+ | Registrar | +-----------+ | | 4 v +-------+ | Data | | Store | +-------+ Figure 3. Buller [Page 8] CCIB (PINT & SPIRITS) December, 2000 The description of the flows shown above is as follows : 1. The user connects. 2. The user (or their ISP) submits Registration details containing CSeq, IP address, telephone number and keys to a web server. 3. The PINT registration message is constructed and sent to PINT server 4. The user details provided are then checked against subscription details and possibly CLI. These details are then stored. 5. The response message is constructed and returned to PINT client. 6. The PINT client informs the Web Server of the status. 7. If the response message to the registration indicates that it was accepted, a 'thin' SPIRITS server applet is sent to the users machine. Only a thin SPIRITS server would be required to handle requests as the exact format of possible SPIRITS requests would be known for this service. 5.1.2. Call Attempt Phase The description of the flows shown below (in figure 4) is as follows : 1. The call attempt is made. The PSTN/ IN detects call in progress and busy SPIRITS subscriber line. It then plays an announcement to the calling party. Next, the PSTN/ IN initiates a request to the SPIRITS client, using some other protocol (which could be INAP). 2. The SPIRITS client issues the SPIRITS invitation request. 3. Presently registered details are looked up. 4. The final SPIRITS invitation request is constructed and sent. Then one of two things can occur detailed in 4a and 4b. 4a. The invitation request is received by the called party. Continue to flow 5. 4b. The invitation request does not reach the intended recipient or times out. A failure message is returned to the SPIRITS client on the initiative system. 5. The 'thin' SPIRITS server applet on the called party's machine receives the invitation request and allows the user to decide how this call should be handled. Possible options here could be : a) Drop the Internet connection and take the call over the PSTN /IN system. Buller [Page 9] CCIB (PINT & SPIRITS) December, 2000 b) Accept the connection via a VoIP gateway in the PSTN/ IN. c) Pass the call on to a Voice Mail system. d) Play Announcements. e) Refuse the call. 6. The called party's wishes are contained in this response which is passed back to the initiative system. +----------------+ | User Equipment | | +----------+ | | | SPIRITS | | 5 | | Server | | | +----------+ | | +-------+ | | | Modem | | ()-() | +-------+ |--- /^\ +----------------+ --- ^ | 4a| 6| | | | v .......... ...../ \..... ....../ \...... / \ | Internet | \...... ....../ \..... ...../ \........../ ^ | 4| |4b/6 | | +------------------+ | v |Initiative System | +-----------+ 4b/6 +--------+ | | SPIRITS |----->| SPIRITS| | | Server |<-----| Client | | +-----------+ 2 +--------+ | ^ | | | | v +------------------+ +-----------+ ^ | Registrar | | +-----------+ | | ^ | | | 1| 3| 3| | v | | +-------+ ()-() | Data | /^\ | Store | --- +-------+ Figure 4. Buller [Page 10] CCIB (PINT & SPIRITS) December, 2000 Note! Due to the fact that registration is issued by the subscriber, not hand crafted or permanently pinned-up by the service provider, this inherently provides the possibility of service mobility. A subscriber 'may' register themselves on any number. There are obvious security concerns with this and these are discussed in other sections of this Internet Draft. 6. Security Implications It is acknowledged that there are some serious security implications which arise in consideration of such an implementation. These issues are primarily related the registration and de-registration phases. 6.1. Registration A user may attempt to Register for this service on another's number (by accident or design) in order to claim notification on a line they have no right to. In a 'real world' implementation of this service this security issue will need to be resolved. As well as the use of standard security mechanisms such as passwords and keys, more secure implementations could undertake to : 1) Only allow this kind of access from the user's own phone. 2) Provide functionality to check the actual CLI from which the user issued their Registration (as highlighted early). 3) Only provide two possibilities on 'untrusted' (e.g. "roaming" or "non home") numbers, that is drop the current Internet connection and establish a POTS call, or ignore the SPIRITS message. 4) Maintain good accounting in order to track offenders down. 6.2. De-registration The de-registration problem would arise if a user did not de-register themselves before they finished using the Internet. This likely to be a common occurrence e.g. users turning off their machines/ modems without de-registering. It is expected that any implementation should build in a mechanism to handle this scenario. Authenticators could be passed in responses to the registration messages sent to the SPIRITS service on the user's machine. Alternatively, these authenticators could be placed directly in the SPIRITS 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. Buller [Page 11] CCIB (PINT & SPIRITS) December, 2000 2) The line is busy on a voice call. An attempt to send a INVITE message fails (as there would be no receiving SPIRITS server). Any previously held registration for this number could then be 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 SPIRITS 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. 7. Conclusions This Internet Draft has initially provided an overview description of how the PINT and SPIRITS paradigms differ. However, it has also shown how they may be used together in the provision of services. Various required entities, mechanisms and their location required in the provision of an ICW/ CCIB service have also been discussed. This Internet draft has detailed an implementation of CCIB which uses PINT and SPIRITS 'like' functionality in provision of two aspects of the one service. Buller [Page 12] CCIB (PINT & SPIRITS) December, 2000 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. [3] Handley, M., Jacobson, V., "SDP Session Description Protocol" RFC 2327, April 1998. [4] 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 CCIB Call Completion Internet Busy ICW Internet Call Waiting IN Intelligent Network PINT PSTN Internet working POTS Plain Old Telephone Service PSTN Public Switched Telephone Network SDP Session Description Protocol SIP Session Initiation Protocol SoP Some other Protocol (used within the PSTN) VoIP Voice over IP (Internet Protocol) 9. Acknowledgments The author would like to acknowledge the following people. Lawrence Conroy for proof reading this document. 10. Author's Address Jim Buller Unisphere Solutions, 900 Broken Sound Parkway, B12S Boca Raton, FL 33487 USA Telephone: +1 561 923 3132 E-mail: jbuller@unispheresolutions.com Buller [Page 13]