IPTEL Working Group                       Janusz Dobrowolski
                                          Warren Montgomery
                                          Kumar Vemuri
Internet Draft                            John  Voelker
                                          Alec  Brusilovsky
                                          Lucent Technologies

Expires: December 1999


     IN Technology for Internet Telephony Enhancements

                <draft-dobrowolski-iptel-in-00.txt>


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.














                           - 2 -



.  Abstract


The purpose of this Internet Draft is to start discussion on
the issues of making available existing Intelligent Network
(IN) capabilities to the Voice over IP (VOIP) Internet
application and other Internet applications.  In addition to
benefitting from accessing existing IN services,
interworking with IN will expedite development of new
Internet applications.

The goal of this contribution is to assist: A) in
development of new voice over Internet (VOIP) applications
interworking with IN, B) making available to existing VOIP
applications existing IN services, C) making available to
non-VOIP Internet applications existing IN services, D)
perhaps new non-VOIP Internet applications using existing IN
services.



.  Motivation


The widespread adoption of VOIP technology by end-users
requires enhanced services.  These services can be provided
by exploiting the existing Intelligent Network
infrastructure. The IN infrastucture is well established and
has a proven track record of high capacity, scalability, and
robustness.  Although the reliability of the existing IN is
based partly on the robustness of SS7; it also derives from
the high reliability of the SCP equipment which could be
adapted to provide services without SS7.  Incidentally, the
SCP may also be a suitable platform to implement reliable
policy/profile servers for the Internet.

In addition, the IN has wide user/business acceptance.
Users of VoIP applications would benefit from consistent
feature operation for both PSTN and IP end-points.
Interworking VOIP with IN services in the existing wireless
and wireline networks provides this consistency.  The
benefits of consistency accrue not only to the end-users but
also to network operators. This efficiency comes from











                           - 3 -



reducing the need for separate maintenance of user and
service (e.g. "follow me") data for IP and PSTN end-users.



.  IN/VOIP Interworking


In order to both use existing IN services and to develop new
services using existing IN capabilities, it is necessary for
call control functions in the Internet to interwork with a
Service Control Point (SCP). Through a transaction oriented
protocol the SCP can direct the routing and call logic
sequencing of the Service Switching Point (SSP).  The SSP,
following a finite state machine call model [3], reports
particular call events to the SCP which then applies its
database and service logic capabilities to tell the SSP what
to do next.

The network view shown in Figure 5 in [5] illustrates how IN
equipment can fit into the network world. (The SSP function
is performed by the call controllers in this figure.  For
clarity, we are referring to this function in the IP network
as the soft SSP.)


3.1  Why use a Call Model?


Some IN services (e.g. number portability, simple 800 calls)
involve relatively simple database lookups on the SCP and a
single message exchange with the SSP.  For such services, it
would be possible for the call controller to formulate a
simple query message and process the results without
implementing the complete call state model expected by the
SCP. On the other hand, many services (e.g. advanced 800
service, virtual private network, follow me routing) can not
be implemented using a simple database query.  These service
may involve several message exchanges with the SSP and
require the SSP to implement the IN call model so that both
SSP and SCP have a common context for interpreting those
messages. By implementing the IN call model in the call
controller, the call controller gains access to a











                           - 4 -



significantly richer set of services than can be obtained by
simply querying routing data in the SCP.


3.2  Implementing an SSP call model


To implement an SSP call model, the call controller must
implement the same state machine and trigger points as
defined for a PSTN SSP.  The state model must be implemented
in the context of the state model defined by the IP
telephony protocols in use (e.g. H.323).  In processing the
IP telephony messages related to call control, the call
controller must step through the states defined in the SSP
call model and determine at each transition whether to
trigger a transaction with the SCP.  The processing of a
single call control message or event by the call controller
may cause transition through several IN call model states
and potentially trigger more than one interaction with the
SCP.

Different state models and triggers are applied to the
originating and terminating parties in a call, and the
decision of when to trigger and what information to supply
to the SCP may depend on the identity of the originator or
terminator as well as global information about the call
(e.g. a dialed number representing a feature activation
code).  Mapping of the IN call models and triggers to IP
telephony call control architectures is an area where
standards need to be developed to ensure consistent
implementation.



.  Basic Call State Model


The SSP Call Model is specified in terms of two finite state
machines (O_BCSM and T_BCSM) and is referred to as the Basic
Call State Model (BCSM).  The O_BCSM models the originating
side of the call and the T_BCSM models the terminating side.

Call Models in wireline and wireless telephony are derived











                           - 5 -



from the generic Call Model specified by the International
Telecommunication Union (ITU). Different call models exist
today due to variations in network evolution around the
world and due to the fact that the requirements for wireline
and wireless networks were often developed separately.



.  The Soft SSP


To use the IN services you have to implement the SSP
function.  To refer to an SSP designed for use in the
Internet environment we adopt the term soft SSP. For an SCP
to interwork with a soft SSP, the SCP must either support
TCAP over IP or the soft SSP must support TCAP over SS7. In
the latter case, either the SSP could support SS7 directly
or a signaling gateway could provide this signaling
interworking.

A closely related issue is that a soft SSP needs to identify
the particular SCP appropriate to handle a particular
trigger.  Also, the SCP must be able to return a response to
the correct soft SSP.  This translation function, known to
the telephony community as Global Title Translation (GTT),
is provided in the PSTN by the SS7 protocol stack.

The issue of protocol interworking at the layers below TCAP
and the issue of providing GTT functionality are not
intended to be addressed here except to note that various
solutions have been proposed.

With H.323 the Gatekeeper provides a possible place to
implement the soft SSP function.  With SIP, a proxy server
may assume this role. A media gateway controller is another
possibility.


















                           - 6 -



.  Call Processing Language (CPL) and IN


CPL[4] is structured as set of condition/action pairs.  CPL
conditions detected in the soft SSP may reflect call model
detection points or triggers as well as TCAP messages
incoming from the SCP.  CPL action scripts may include the
action of sending a particular TCAP messages to an SCP to
invoke its service logic capabilities.



.  Security Issues


Access to IN components must be controlled and regulated
very carefully since security can be more easily breached
through the IP network.  Since IN components (SCPs and
Intelligent Peripherals) may be shared by PSTN end-users and
IP end-users, services to both groups could otherwise be
compromised.  A thorough analysis of these issues merits its
own draft.



.  Call Model Standards


The most widely deployed SSP call models today are in:
                1) AIN.1 for Wireline Network
                2) IS-41 for Wireless Network
                3) ETSI for Wireline Network
                4) GSM Wireless Network

The above Call Models are documented in the
following standards:

The next three specifications are for landline IN.

The ETSI (www.ETSI.fr) call model for the SSP is  ETSI 300-374.

ITU (www.itu.ch) Defines call models for both Capability Set 1
(CS1) and Capability Set 2 (CS2).











                           - 7 -



The former is used in the current installed
base of IN equipment.  The later is coming on stream.
For CS1, the call model for the SSP is ITU-T Recommendation Q.1214.
For CS2, the call model for the SSP is ITU-T Recommendation Q.1224.
These models serve as reference models.

The Bellcore (www.bellcore.com) model is known as AIN.1.
The call model for the SSP is contained in GR1298.

These next two specifications are for wireless IN.

The GSM call model is contained in Q.1224 with minor augmentation by
CAMEL.  CAMEL (Customized Application for Mobile network Enhanced Logic)
is an ETSI GSM standard.  See GSM 03.78 for the call model.

The ANSI (www.ansi.org) specification is known as IS41.
Its SSP call model is the TIA document TN3661
(out for ballot for Wireless IN Distributed Functional Plane)



.  References


[] J. Postel, RFC 1543, "Instruction to RFC Authors".
October 1993

[] ITU-T Q.12xx Recommendation Series, Geneva, 1995.

[] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J.
Shah, "The Intelligent Network Standards, their Application
to Services". McGraw-Hill, 1996.

[] J. Lennox, H. Schulzrinne,  "Call Processing Language
Requirements",
    July 30, 1998.

[] F. Cuervo, N. Greene, M. Holdrege, L. Ong, C. Huitema,
    "SS7-Internet Interworking - Architectural Framework",
July, 1998.














                           - 8 -



.  Authors' Address


Janusz Dobrowolski
E-mail: jdobrowolski@lucent.com
Telephone: +1-630-979-6698
Fax: +1-630-713-5840
Lucent Technologies
 Shuman Blvd.
Naperville, IL 60566 USA

Warren Montgomery
E-mail: wamontgomery@lucent.com
Telephone: +1-630-713-5090
Fax: +1-630-713-5840
Lucent Technologies
 Shuman Blvd.
Naperville, IL 60566 USA

Kumar Vemuri
E-mail: vvkumar@lucent.com
Telephone: +1-630-224-2406
Fax: +1-630-713-5840
Lucent Technologies
 Shuman Blvd.
Naperville, IL 60566 USA

John Voelker
E-mail: jvoelker@lucent.com
Telephone: +1-630-713-5538
Fax: +1-630-713-5840
Lucent Technologies
 Shuman Blvd.
Naperville, IL 60566 USA

Alec Brusilovsky
E-mail: abrusilovsky@lucent.com
Telephone: +1-630-713-8401
Fax: +1-630-713-5840
Lucent Technologies
 Shuman Blvd.
Naperville, IL 60566 USA












                           - 9 -



.  Glossary


AIN                     Advanced Intelligent Network
IN                      Intelligent Network
PSTN                    Public Switched Telephone Network
SCP                     Service Control Point
SSP                     Service Switching Point
VoIP                    Voice over IP (Internet Protocol)




.  Acknowledgments


The authors would like to acknowledge Jack Kozik and John
Stanaway for their insightful comments presented at the
working discussions that lead to the creation of this
document.