Network Working Group I. Faynberg
Internet Draft Lucent Technologies
<draft-faynberg-spirits-inpintreqs-02.txt> J. Gato
Expires June 2001 Airtel Movil
H. Lu
Lucent Technologies
L. Slutsman
AT&T
IN- and PINT-related Requirements for SPIRITS Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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.
1. Abstract
This Internet-Draft is written in response to the SPIRITS WG chairs'
call for contributions to the future RFC on the SPIRITS protocol
requirements. This document does not contain the full set of such
requirements. Its goal is to introduce the requirements pertinent to
Intelligent Network (IN), Wireless IN, and the (future) work of
PSTN/Internet iNTernetworking (PINT) WG. The present version of the
document differs from the previous one in that it contains wireless IN
material.
2. Conventions
In examples, "C:", "P", and "S:" indicate lines sent by the client,
Proxy, and server respectively.
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.
IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman November 2000
<draft-faynberg-spirits-inpintreqs-01.txt> [Page 2]
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 characteristic--being invoked
from an IP network (vs. PSTN).
3. Introduction
This Internet-Draft is written in response to the SPIRITS WG chairs'
call for contributions to the future RFC on the SPIRITS protocol
requirements. This document does not contain the full set of such
requirements. Its goal is to introduce the requirements pertinent to
Intelligent Network (IN), Wireless IN, and the (future) work of
PSTN/Internet iNTernetworking (PINT) WG. The present version of the
document differs from the previous one in that it contains wireless IN
material.
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 Proxy. The SPIRITS Proxy 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 Central Office.)
IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman November 2000
<draft-faynberg-spirits-inpintreqs-01.txt> [Page 3]
Subscriber's IP Network
IP Host
_______________ ....................
| _____________ | A . ________________ .
| |PINT Client|*******| PINT Server |********
| |___________| | . |______________| . *
| ____________ | . * . *
| | SPIRITS | | B . _______*________ . *
| | Server |*******|SPIRITS Proxy | . *
| |___________| | . |______________| . *
|_______________| .........*.......... *
*C *
_________________ ______*________ *
| Subscriber | |SPIRITS Client | *
| Telephone | | *
|_________________| |_______________| *
* * * E
* Line * D *
++++++++++*+++++++++++PSTN+++++*+++++++++++++++*++
* * *
+----------------+ +------------------------+
| SSP(Switch) |*****| SERVICE CONTROL |
| | | |
+----------------+ SS7 +------------------------+
Figure 1. Joint PINT/SPIRITS Architecture
With PINT (and that also applies to the present 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 and SPIRITS
Proxy 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 Proxy or PINT Server and SPIRITS Client other then
by listing the overall PINT-related requirements.
Since the wireless networks currently deployed worldwide 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, location information
IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman November 2000
<draft-faynberg-spirits-inpintreqs-01.txt> [Page 4]
could be handled in the IP network).
Nevertheless, there are certain peculiarities of Wireless networks,
which force considerations to be made in the in the protocol
requirements and in the SPIRITS architecture.
The particular Wireless IN standard development being considered here
is Customized Application for Mobile Network Enhanced Logic (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 SSP. These events are communicated to Service Control, at
which point they use the same mechanism for invoking SPIRITS services
as in the IN case.
The rest of this Internet-Draft addresses the general IN
Requirements, specific Wireless IN requirements, PINT Requirements,
the protocol development methodology, and security issues, in that
order.
4. IN Requirements
The interface immediately relevant to IN is that between the SPIRITS
Client and SPIRITS Proxy (interface C). A typical message (which
starts a SPIRITS service) looks like that:
C -> P: <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:
1) The list of the DPs to be covered encompasses those defined in the
IN Capability Set 3 BCSM as well as those related to the Wireless IN
(WIN) as specified by 3GPP and 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.) In case 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
IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman November 2000
<draft-faynberg-spirits-inpintreqs-01.txt> [Page 5]
of the ASN.1 nor the requirement for binary encoding is a typical
requirement 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. A work-in-progress SIP
proposal [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
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); 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 Proxy, 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-2 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 completed and
IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman November 2000
<draft-faynberg-spirits-inpintreqs-01.txt> [Page 6]
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, and paging.)
- o_no_answer, route_select_failure, and t_no_answer
(to re-route a call)
- o_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, and paging.)
With that, the only DPs needed to implement the present SPIRITS
milestone services are
- termination_attempt_authorized (needed for SPIRITS
"milestone" services)
- 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 there is no DP (as compared
with IN CS3) for consideration, 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
IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman November 2000
<draft-faynberg-spirits-inpintreqs-01.txt> [Page 7]
one of the parameters in the Event Notification message (from
SPIRITS Client to SPIRITS Proxy, 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 the SPIRITS protocol.
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
the 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 proxy).
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.
- International Mobile Subscriber Identity (IMSI) attach.
- Mobile Station (MS) initiated IMSI detach.
- Network-initiated IMSI detach.
With this mechanism, the SPIRITS services can use the 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 a supplementary service, such as
Explicit Call Transfer, Call Deflection, Call Completion on
Busy Subscriber, or Multi-Party.
6. PINT-related Requirements
Before a SPIRITS service can be invoked, the relevant IP Host must be
registered. Thus, Registration is an essential service (not yet
addressed by PINT), which is initiated from the IP side. The
registration information is ultimately used by the PSTN to
IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman November 2000
<draft-faynberg-spirits-inpintreqs-01.txt> [Page 8]
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 to by the PINT server to the
SPIRITS Proxy and SPIRITS Client:
PINT C.: -- REGISTER --> PINT S. [--> SPIRITS Proxy --> 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.
As noted in 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 this 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.
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.
IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman November 2000
<draft-faynberg-spirits-inpintreqs-01.txt> [Page 9]
|----> REGISTER ----->|
SPIRITS |<---- EVENT <-----|SPIRITS
Proxy |----> 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->P: <Accept Call>
b) S->P: <[Reject Call],[Cause]>
c) S->P: <[Redirect Call],[Redirection Destination]>
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-2 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.
IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman November 2000
<draft-faynberg-spirits-inpintreqs-01.txt> [Page 10]
Parameters should be event-specific, the folowing generic types of
parameters are expected to be mandatory:
- timer (for no answer)
- midcall control infomation (for mid_call)
- number of digits (for collected_information)
9. Security Considerations
It is assumed that the interface C is between trusted entities. Thus,
there are no particular IN-related or requirements to the protocol
pertinent to this interface. 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 the same.
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
John Voelker for his incisive comments.
11. References
[1] L. Slutsman (Ed.) et al, The SPIRITS Architecture. <draft-ietf-
spirits-architecture-00.txt>, Work in Progress. October 2000.
[2] H. Lu (Ed.) et al, Pre-SPIRITS Implementations of PSTN-initiated
Services, <draft-ietf-spirits-implementations-02.txt>, Work in
Progress. July 2000.
[3] S. Petrack, and L. Conroy, The PINT Service Protocol: Extensions
to SIP and SDP for IP Access to Telephone Call Services, Proposed
Standard. RFC 2848.
[4] A. Roach, Event Notification in SIP, <draft-roach-sip-subscribe-
notify-01.txt>, Work in Progress. October 2000.
12. Author's 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
IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman November 2000
<draft-faynberg-spirits-inpintreqs-01.txt> [Page 11]
Room 4C-611A, 101 Crawfords Corner Road
Holmdel, New Jersey, 07733
Phone: (732) 949-0137
Email: faynberg@lucent.com
Jorge Gato
Airtel Movil, S.A.
Avda de Europa, 1.
28108 Alcobendas (Madrid). Spain
Tel: +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
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 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.
IN/PINT Requirements-Faynberg-Gato-Lu-Slutsman November 2000