summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3298.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3298.txt')
-rw-r--r--doc/rfc/rfc3298.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc3298.txt b/doc/rfc/rfc3298.txt
new file mode 100644
index 0000000..15d743d
--- /dev/null
+++ b/doc/rfc/rfc3298.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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.
+
+Abstract
+
+ This 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.
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 1]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+1. Conventions used in this document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in 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).
+
+2. Introduction
+
+ This 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. 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 [1]) 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 [2].)
+
+ 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
+
+
+
+Faynberg, et al. Informational [Page 2]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+ 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.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 3]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+ ......................
+ +----------------+ . .
+ | +------------+ | . +------------+ .
+ | | | | 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
+
+
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 4]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+ With PINT (and that also applies to the PINT architecture and
+ protocol as described in [3]), 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 [3]) 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.
+
+
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 5]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+3. General Requirements
+
+ Based on the success of extending SIP for PINT ([3]) and, especially,
+ the results of pre-SPIRITS implementations reported in [2], the
+ Session Initiation Protocol (SIP) [7] 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) [8] or Multi-purpose
+ Internet Mail Extensions MIME [5-6] may be used for this purpose.
+ Except for the proposed new SUBSCRIBE/NOTIFY mechanism [4], 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 [2] 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.
+
+4. IN Requirements
+
+ The interface immediately relevant to IN is that between the SPIRITS
+ Client and SPIRITS Gateway (interface C). A typical message (which
+ starts a SPIRITS service) looks like this:
+
+ C -> G: <Event Notification>, <Parameter-List (DP)>
+
+ The relevant events correspond to the detection points (DPs) of the
+ IN Basic Call State Model (BCSM). The <Parameter-List> is a function
+ of a specific DP; it contains the parameters relevant to it. The
+ following requirements apply:
+
+
+
+Faynberg, et al. Informational [Page 6]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+ 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 [4] 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
+
+
+
+Faynberg, et al. Informational [Page 7]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+ 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.)
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 8]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+ 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).
+
+5. Wireless-IN-related Requirements
+
+ Wireless IN covers several types of "calls," which are neither
+ circuit switched nor have an effect on circuit switched calls. For
+ this reason, those are not considered in SPIRITS requirements. To
+ further clarify this point, the types of "calls" not considered are:
+
+ - USSD (Unstructured Supplementary Service Data)
+
+ - GPRS (General Packet Radio System)
+
+ - SMS (Short Message System)
+
+ The types of calls relevant to SPIRITS are as follows:
+
+ a) Voice Calls. In this case no new DP is needed since CAMEL DPs
+ are included in CS2. The only special case is "Not Reachable"
+ (when it is detected that the mobile user is out of coverage or
+ has switched off), which is mapped as a special cause in the
+ Busy DP. Since the Busy DP parameters would be received (if a
+ SPIRITS service has subscribed to Busy), it would be possible
+ to distinguish a "busy" from a "not reachable" situation.
+
+ This translates into the requirement that one of the parameters
+ in the Event Notification message (from SPIRITS Client to
+ SPIRITS Gateway, over the interface C) denotes the "cause" for
+ the Busy Detection Point.
+
+ Another aspect of difference, when compared to PSTN, is setting
+ of static DPs. In CAMEL networks, this is done in the Home
+ Location Register (HLR) (and copied to the VLR during location
+ update). It is important to note this difference, even though
+ it has no effect on SPIRITS protocol.
+
+
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 9]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+ 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.
+
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 10]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+6. PINT-related Requirements
+
+ Before a SPIRITS service can be invoked, the relevant IP Host must be
+ registered. Thus, Registration is an essential service, which is
+ initiated from the IP side. The registration information is
+ ultimately used by the PSTN to authenticate the subscriber.
+
+ Depending on the model, this can be done in two ways with the present
+ architecture:
+
+ 1) The PINT Client issues the appropriate Register message over the
+ interface A, which is then passed by the PINT server to the SPIRITS
+ Gateway and SPIRITS Client:
+
+ PINT C.: -- Register --> PINT S. [--> SPIRITS Gateway --> SPIRITS
+ C.]. In this case the SPIRITS Client (co-located with the service
+ control) is responsible for record keeping and the authentication.
+
+ 2) The PINT Client issues the appropriate Register message to the
+ PINT Server, which then passes this information to the PSTN service
+ control "by magic".
+
+ The second model is much easier to handle, because it involves only
+ one relevant interface ("A"); however it assumes no interworking
+ between PINT and SPIRITS except that the SPIRITS Client finds "by
+ magic" that a friendly and expecting IP Host is alive and well.
+
+ Finally, in the event PINT is not implemented, the SIP SUBSCRIBE
+ mechanism can be used.
+
+ As noted in the previous section, the existing SUBSCRIBE/NOTIFY PINT
+ building blocks [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 [4]; 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).
+
+7. Follow-up on Event Notifications
+
+ The requirements of this section are neither PINT-specific, nor IN-
+ specific; their role is to outline the remaining element necessary
+ for the delivery of the SPIRITS service, which is the reaction to the
+ notification received.
+
+
+
+
+Faynberg, et al. Informational [Page 11]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+ 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]>
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 12]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+8. Methodology
+
+ To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set
+ of messages), the PSTN events associated with each detection point of
+ the Basic Call State Model should be examined. To date, the CS-3
+ BSCM has the richest set of DPs, although not all switching exchanges
+ have implemented it.
+
+ To determine the MINIMUM information available to the SPIRITS client
+ (this information is to be carried by the SPIRITS protocol from
+ SPIRITS client to SPIRITS server), each DP-specific information
+ elements needs to be examined.
+
+ Parameters should be event-specific, the following generic types of
+ parameters are expected to be mandatory:
+
+ - timer (for no answer)
+
+ - midcall control info (for mid_call)
+
+ - number of digits (for collected_information)
+
+9. Security Considerations
+
+ Overall, the basic aspects of security apply to SPIRITS protocol:
+
+ - Authentication:
+ In the communications between the SPIRITS Client and SPIRITS
+ Gateway as well as the SPIRITS Gateway and SPIRITS Server, it is
+ required that the information be sent between known and trusted
+ partners.
+
+ - Integrity:
+ It is a requirement that no exchanged data be modified in transit.
+
+ - Confidentiality:
+ It is a requirement that any private user information or
+ confidential network data be protected by the protocol (typically
+ through encryption, for which the protocol should allow a choice
+ in the algorithm selection.
+
+ - Availability:
+ It is a requirement that the communicating endpoints remain in
+ service for authorized use only.
+
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 13]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+ 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 [3].
+
+ 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.
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 14]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+10. Acknowledgements
+
+ The authors are grateful to all participants in the SPIRITS group for
+ the discussion that has been shaping this work. Many thanks go to
+ Jorgen Bjorkner, Alec Brusilovsky, Jim Buller, Lawrence Conroy, Soren
+ Nyckelgard, and John Voelker for their incisive comments. Special
+ thanks are to Vijay Gurbani, Dave Hewins, and Kumar Vemuri, whose
+ careful, detailed reviews of several versions of this document have
+ been particularly helpful in improving its quality.
+
+11. References
+
+ [1] Slutsman, L., Faynberg, I., Lu, H. and M. Weissman, "The Spirits
+ Architecture", RFC 3136, June 2001.
+
+ [2] 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.
+
+ [3] 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.
+
+ [4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
+ Notification", RFC 3265, June 2002.
+
+ [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message Bodies",
+ RFC 2045, November 1996.
+
+ [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046, November
+ 1996.
+
+ [7] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg,
+ "SIP: Session Initiation Protocol", RFC 2543, March 1999.
+
+ [8] Handley, M. and V. Jacobsen, "SDP: Session Description
+ Protocol", RFC 2327, April 1998.
+
+
+
+
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 15]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+12. Authors' Addresses
+
+ Lev Slutsman
+ AT&T Laboratories
+ 200 Laurel Ave.
+ Middletown, New Jersey, 07748
+
+ Phone: (732) 420-3752
+ EMail: lslutsman@att.com
+
+
+ Igor Faynberg
+ Bell Labs/Lucent Technologies
+ Room 4D-601A, 101 Crawfords Corner Road
+ Holmdel, New Jersey, 07733
+
+ Phone: (732) 949-0137
+ EMail: faynberg@lucent.com
+
+
+ Jorge Gato
+ Vodaphone
+ Avda de Europa, 1.
+ 28108 Alcobendas (Madrid). Spain
+
+ Phone: +34 607 13 31 10
+ Fax: +34 607 13 30 57
+ EMail: jgato@airtel.es
+
+
+ Hui-Lan Lu
+ Bell Labs/Lucent Technologies
+ Room 4C-607A, 101 Crawfords Corner Road
+ Holmdel, New Jersey, 07733
+
+ Phone: (732) 949-0321
+ EMail: huilanlu@lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 16]
+
+RFC 3298 SPIRITS Protocol Requirements August 2002
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faynberg, et al. Informational [Page 17]
+