Network Working Group I. Faynberg, Editor Request for Comments: 3298 Lucent Technologies Category: Informational J. Gato Vodaphone H. Lu Lucent Technologies L. Slutsman AT&T August 2002 Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.
AbstractThis document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN. To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol.
RFC 2119. Unless otherwise qualified, the term PINT is used here not to refer to the present PINT services and protocol, but in reference to the scope of the generic PINT (vs. SPIRITS) service characteristics-- services being invoked from an IP network (vs. PSTN). RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service.") The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN. To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. The joint PINT/SPIRITS architecture (described in ) is depicted in Figure 1. It is assumed that the Spirits Client is either co-located with the IN Service Control Function (SCF) or communicates with it (over the PSTN-specific interface D) in such a way so as to act on behalf of the PSTN/IN. (This assumption is confirmed by current implementations, as reported in .) The SPIRITS services are invoked (and, subsequently, the SPIRITS protocol is initiated) when a message from a SPIRITS Client (located in the IN Service Control Point [SCP] or Service Node [SN]) arrives on interface C to the SPIRITS gateway. The Spirits gateway processes the message and, in turn, passes it on over the Interface B to the SPIRITS server. In most practically important cases, the request from a SPIRITS client is ultimately caused by a request from a Central Office (i.e., a telephone switch) sent to either the SCP or
SN, although the Internet-based service initiation by these elements that had not been triggered by the Central Office is theoretically possible. (Definitely, none of the SPIRITS benchmark services are initiated in such a way, so, for the purposes of the SPIRITS protocol development, it should be assumed that the service invocation was a direct result of an earlier action by the Service Switching Function.)
...................... +----------------+ . . | +------------+ | . +------------+ . | | | | A . | | . | | PINT Client|********************|PINT Server/|******** | | | | . | Gateway | * | +------------+ | . +------------+ . * | | . . * | Subscriber's | . . * | | . . * | IP Host | . . * | | . +------------+ . * | +------------+ | . | SPIRITS | . * | | SPIRITS | | B . | Gateway | . * | | Server |********************| | . * E | | | | . +------------+ . * | +------------+ | . * . * +----------------+ . * . * ...........*.......... * * * * * Subscriber's * C * Telephone * * * * (---) * * * * * * * * * ++++++++++++++++++++++++++ PSTN ++++++++++++++++++++++++++ * * * * * * * +------------------+ * * Line | SPIRITS Client | * * | | * +--------------------+ +---+----- D ---------+-*+ | | INAP/SS7 | | |Service Switching ************Service Control Function | | Function | | | | | +-------------------------+ | | | | +--------------------+ Figure 1. Joint PINT/SPIRITS Architecture
With PINT (and that also applies to the PINT architecture and protocol as described in ), the service request to the PINT Server is always initiated by the PINT Client over the interface A. The PINT Server can either be co-located with the IN Service Control or a similar entity (referred to as "Executive System" by ) or communicate with it over the PSTN-specific interface E. As Figure 1 shows, the PINT Client and SPIRITS Server are co-located in Subscriber's IP Host. In fact, both can be implemented to run as one process. No provision is made for interactions between the PINT Client and Spirits Server. Similarly, the PINT Server/PINT Gateway and SPIRITS gateway are assumed to be co-located, too. This assumption is convenient but not essential; the PINT Server could also be co-located with the SPIRITS Client. In either case, no specific provision is made to define interworking between either the PINT Server and Spirits Gateway or PINT Server and SPIRITS Client other than by listing the overall PINT-related requirements. Since the currently deployed worldwide wireless networks are based on circuit switching, they are considered PSTN networks for the SPIRITS purposes. Adding SPIRITS type of services to wireless networks can allow new services to be developed (for example geolocation information can be handled in the IP network). Nevertheless, there are certain peculiarities of wireless networks, which force considerations to be made in the protocol requirements and in the SPIRITS architecture. A particular Wireless IN standard development being considered here is CAMEL phase 3, standardized by the Third Generation Partnership group (3GPP). The relevant service and architectural considerations and protocol requirements are presented later in this document. As far as the architecture is concerned, certain wireless events are generated by Home Location Register (HLR), which may, but does not have to, be part of the Mobile Switching Center (MSC) (a wireless equivalent of the SSP). These events are communicated to Service Control, at which point they use the same mechanism for invoking SPIRITS services that the IN would. The rest of this document addresses the general requirements, IN Requirements, specific Wireless IN requirements, PINT Requirements, the protocol development methodology, and security issues, in that order.
3]) and, especially, the results of pre-SPIRITS implementations reported in , the Session Initiation Protocol (SIP)  has been chosen as the signaling base protocol for SPIRITS. Thus, it is a requirement that specific SPIRITS-related parameters be carried in a manner consistent with SIP practices. In particular, either Session Description Protocol (SDP)  or Multi-purpose Internet Mail Extensions MIME [5-6] may be used for this purpose. Except for the proposed new SUBSCRIBE/NOTIFY mechanism , and extensions already defined in PINT, no new SIP extensions are foreseen; instead the SPIRITS protocol is to rely on the above extension mechanisms. It is by no means a requirement that any SPIRITS implementation automatically support PINT services. The SPIRITS protocol must be defined in a manner where, as the minimum, it can support only the basic notification mechanism without relying on PINT services or otherwise relying on persistent interactions with PSTN. Nevertheless, it has been demonstrated  that combining PINT building blocks with those of SPIRITS is beneficial to building rich, enhanced PSTN/Internet services, so the SPIRITS protocol must meet the PINT-related requirements listed in section 7 of this document. One specific example demonstrating the application of the latter requirement, which is elaborated on further in this document, is as follows: Implementation of SUBSCRIBE/NOTIFY is not mandatory as far as the minimum SPIRITS protocol is concerned. Thus, the initial PSTN (Detection Point) notification will always arrive via the SIP INVITE method; however, to implement persistent interactions with the PSTN, the SUBSCRIBE method may be used to obtain further notifications of the PSTN events. Subsequently, these events will be reported on by means of the NOTIFY method.
1) The list of the DPs to be covered encompasses those defined in the IN Capability Set 3 BCSM as well as those which relate to the Wireless IN (WIN) specified by the IMT 2000 project in ITU-T. 2) Not all parameters associated with such DPs are needed by the SPIRITS benchmark services, nor may all the parameters be needed in SPIRITS. The selection of the relevant parameters is part of the SPIRITS protocol definition. 3) It is desirable to avoid semantic overload of protocol messages. (One way to achieve that is to match each type of an event with a message that corresponds to it.) As the SPIRITS protocol is designed as a set of extensions to another (existing) protocol with the defined message set, the syntax and semantics of the extensions should be defined with this requirement in mind. 4) The ITU-T Recommendations use the abstract syntax notation (ASN.1) to specify the semantics of the IN Application Protocol (INAP) parameters, which are expected to be binary-encoded. Neither the use of the ASN.1, nor the requirement for binary encoding are the typical requirements for the IETF application protocols. Recognizing that, provisions must be made for careful specification of the conversion of the INAP parameters to text, which must preserve their original semantics. The actual conversion of the parameters is the function of the SPIRITS Client. In order to issue an initial query (or a notification) to service control, a switch must have such a DP set. This can be done statically via service management (this particular action should be left to implementation and thus is considered outside of the scope of SPIRITS Protocol) or dynamically--but only for the purpose of a particular call--from the service control. In the latter case, it is part of the SPIRITS (or PINT) protocol to request the event notification from the service control. The SIP specific event notification scheme  should be specifically considered. This function can be performed by either the Spirits Client or PINT Server, the distinction being further discussed in the next section. Assuming that it is performed by the SPIRITS Client, the relevant message should look like: G->C: SUBSCRIBE <Event> <Mode> <DP-specific parameters>, where <Event> refers to a particular DP; <Mode> determines whether the Event Detection Point (EDP) is to be armed as EDP Request (EDP-R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is not foreseen because it would not provide any additional capability for SPIRITS); and the <DP-specific parameters> is the
list of the values of the parameters associated with the EDP (for example, if the DP in question is O_No_Answer, then the value of the appropriate timer should be included in the list). Note that such a subscription may also originate at a) PINT Client or b) SPIRITS Gateway, either of which may (but does not have to) have a locally significant definition of the <Event>. In either case, it is the function of the SPIRITS Client to translate the definition of the Event into a particular DP (or set of DPs) when passing the message to Service Control. To summarize, for the case when PINT and SPIRITS events are defined in a way where they do not refer to the BCSM DPs, it is the function of the SPIRITS Client to define a mapping: Event -> DP List, for each event for which the PSTN notification is needed. The list of CS-3 DPs envisioned in SPIRITS is: - origination_attempt_authorized (the SPIRITS service can control call attempts, (for example, to limit calls during specific time periods) - collected_information and analyzed_information (for SPIRITS outgoing call screening) - o_answer, o_term_seized, and t_answer (to release SPIRITS resources after the call is complete and perform relevant OA&M actions such as creating a record of attempts to reach a party via various means like land-line phone, cell phone, SMS, or paging.) - o_no_answer, route_select_failure, and t_no_answer (to re-route a call) - o_called_party_busy (to re-route a call and for Internet Call Waiting) - o_mid_call and t_mid_call (to assist a midcall action) - o_abandon, o_disconnect, t_abandon, and t_disconnect (to terminate a SPIRITS service and release the resources and perform relevant OA&M actions such as creating a record of attempts to reach a party via various means like land-line phone, cell phone, SMS, or paging.)
In addition, the following DPs are relevant to the present SPIRITS milestone services: - termination_attempt_authorized - facility_selected_and_available (could be used in SPIRITS Internet Caller-ID) - t_busy (for Internet Call Waiting and Call Forwarding).
b) Mobility Management events. This allows a SPIRITS server to be notified of changes of location of a mobile user. The events would only be applicable to mobile users reachable through a Circuit-Switched network. To provide for this function, the subscription marks must be set in the subscriber's HLR. This is equivalent to setting TDPs in the SSP. In this case, the marks in the HLR (which are copied to the Visitor Location Register [VLR] on location update) are not mapped into Trigger Detection Points. As with TDP setting, this is outside of the scope of SPIRITS protocol. In order to support this function in SPIRITS, the SPIRITS protocol should be able to map the CAMEL specific operations into events notification to the SPIRITS client. Since the SCP receives the information about the mobility state, this involves the C interface. (This is just an extension of the DP notification mechanism from the SPIRITS client to the SPIRITS gateway). The events (which are not DP-related) which need notifications are: - Location Update in the same VLR service area - Location Update in another VLR service area - IMSI attach - MS initiated IMSI detach - Network initiated IMSI detach. With this mechanism, the SPIRITS services can use the user- profile-based location information. For example, the Internet Call Waiting service can re-direct the call to a mobile phone. c) Supplementary Services Notification. This mechanism makes a SPIRITS server aware of a subscriber having invoked one of the following supplementary services: Explicit Call Transfer, Call Deflection, Call Completion on Busy Subscriber, or Multi-Party.
3] must be extended for their use in SPIRITS for the purposes of setting DPs/getting DP event notifications. (A more general SIP mechanism for the same PINT-introduced block is described in ; it provides the necessary mechanism for specifying relevant events.) Conversely, the same building blocks for the functional capabilities can be used in both PINT and SPIRITS protocols. Note, however, that in SPIRITS the PSTN notification may arrive without a particular subscription to an event (in the case of a statically set DP).
In a particular scenario where: a) The IP subscriber registers a SPIRITS service; b) A call triggering the SPIRITS service is received (and notification is sent); and c) The call disposition is performed by the end user, the signalling flow is demonstrated in Figure 2. |----> Registration ----->| SPIRITS |<-- Event Notification <-- | SPIRITS Gateway |---> Call Disposition ---->| Client | | | | | V Service Control | | V SSP Figure 2: Sequence of SPIRITS actions One of the following actions is required by benchmark services: a) Accept the incoming call b) Reject the incoming call c) Redirect the incoming call d) Accept the call via VoIP (this particular item is outside of the scope of SPIRITS WG). Accordingly, the SPIRITS protocol should define the following message types: a) S->G: <Accept Call> b) S->G: <[Reject Call],[Cause]> c) S->G: <[Redirect Call],[Redirection Destination]>
In addition, the protocol should support non-repudiation for those control messages pertinent to charging the PSTN subscriber. As Figure 1 demonstrates, there are two distinct communications interfaces, B and C. The B interface is, in general, across the public Internet and is thus most vulnerable to security attacks resulting in theft or denial of service. The C interface, on the other hand is likely to be implemented across a service providers intranet, where the security measures should be applied at the discretion of the service provider. Even then, because at least one IP host (the PINT gateway) is connected to the Internet, special measures (e.g., installation of firewalls, although this particular measure alone may be insufficient) need to be taken to protect the interface C and the rest of the network from security attacks. The assumption that the PINT Client and SPIRITS server are co- located, dictates that the security considerations for the A and B interfaces are exactly same. Detailed security requirements and solutions for interface A (and, consequently, B) can be found in RFC 2848 . Possible security attacks can result in both theft and denial of services. In addition, such attacks may violate the privacy of a PSTN subscriber. For example, with Internet Call Waiting, a fraudulent registration (or a manipulation of integrity of a valid registration) may force a network operator to provide to an authorized party a full log of attempted telephone calls (accompanied by the identification of callers). Furthermore, the calls may be diverted to wrong recipients (who may further defraud the unsuspecting calling party). In this case, the calling party is using only the PSTN and thus expecting the security of communications that are typical of the PSTN. The PSTN service providers may be liable for the consequences of establishing wrong connections. In addition, the PSTN service providers may be liable for inadvertent divulging of the private information of the subscriber. The service and network providers need to review the possibilities of the security attacks and prepare the means of protection from them. Some of this may be achieved by using the means outside of those provided by the protocol itself. For example, administrative information (such as statistics collected by PINT MIB or SPIRITS MIB) can help in determining violations and thwarting them. As far as the protocol is concerned, it must provide the means for authenticating a subscriber as well as a session. It must also provide a capability to carry encrypted information in its body.
 Slutsman, L., Faynberg, I., Lu, H. and M. Weissman, "The Spirits Architecture", RFC 3136, June 2001.  Lu, H. (Editor), Faynberg, I., Voelker, J., Weissman, M., Zhang, W., Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S., Nyckelgard, S., Yoakum, J. and L. Robart, "Pre-SPIRITS Implementations of PSTN-Initiated Services", RFC 2995, November 2000.  Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, June 2000.  Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.  Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.  Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.