Subject: IP access to intelligent network capabilities

From: "John A. Voelker" <[email-masked]>
Date: Fri, 20 Nov 1998 08:34:32 -0600

The attached file missed by minutes the deadline for submission. So we will use
this more informal means to present these thoughts to the iptel community.

Janusz Dobrowolski
Warran Montgomery
Kumar Vemuri
John Voelker
Alex Brusilovsky

			   - 1 -

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

Expires: May 1999

     IN	Technology for Internet	Telephony Enhancements

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

Status of this Memo

   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.''

   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.

			   - 2 -

1.  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.

2.  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.

3.  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.

4.  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.

5.  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 -

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.

7.  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.

8.  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)

9.  References

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

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

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

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

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

			   - 8 -

10.  Authors' Address

Janusz Dobrowolski
E-mail:	[email-masked]
Telephone: +1-630-979-6698
Fax: +1-630-713-5840
Lucent Technologies
263 Shuman Blvd.
Naperville, IL 60566 USA

Warren Montgomery
E-mail:	[email-masked]
Telephone: +1-630-713-5090
Fax: +1-630-713-5840
Lucent Technologies
263 Shuman Blvd.
Naperville, IL 60566 USA

Kumar Vemuri
E-mail:	[email-masked]
Telephone: +1-630-224-2406
Fax: +1-630-713-5840
Lucent Technologies
263 Shuman Blvd.
Naperville, IL 60566 USA

John Voelker
E-mail:	[email-masked]
Telephone: +1-630-713-5538
Fax: +1-630-713-5840
Lucent Technologies
263 Shuman Blvd.
Naperville, IL 60566 USA

Alec Brusilovsky
E-mail:	[email-masked]
Telephone: +1-630-713-8401
Fax: +1-630-713-5840
Lucent Technologies
263 Shuman Blvd.
Naperville, IL 60566 USA

			   - 9 -

11.  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)

12.  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.