Internet DRAFT - draft-dobrowolski-call-model
draft-dobrowolski-call-model
Internet Engineering Task Force Janusz Dobrowolski
Internet Draft Michel Grech
draft-dobrowolski-call-model-00.txt Shehryar Qutub
June 20, 1999 Musa Unmehopa
Expires: December 20, 2000 Kumar Vemuri
IPTel Working Group Lucent Technologies
Call Model For IP Telephony
<draft-dobrowolski-call-model-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.
Abstract
Several different call models are in common use today in conventional
Telephony. IP Telephony is gaining wider acceptance. There is, as yet,
no well-defined, widely accepted call model for this domain. In this
draft, we study some of the issues associated with call models for IP
Telephony, and suggest how a single call model representation may be
selected to effectively represent call processing in this domain.
1.0 Introduction:
Call Model selection is a subject of substantial interest when issues
involved in implementing VoIP network components are studied, as well as
when interoperability with existing networks is considered.
The SIP RFC [1] defines state machines that depict the operation of the
client and the server when INVITE messages are received (e.g. "Figure
12: State transition diagram of client for INVITE method" and "Figure
13: State transition diagram of server for INVITE method"). However,
there is no definition of an entity called the "SIP Call Model".
There appears to be a notion among some members of software development
community that "if SIP does not have a Call Model then perhaps IP
telephony could be built without a Call Model as well".
[Page 1] Call Model for IP Telephony J. Dobrowolski et al.
Expires Dec 2000.
The "The Session Initiation Protocol SIP" tutorial [2] by Henning
Schulzrinne of Columbia University dated January 18, 2000 contains two
drawings one titled "SIP state transition - server" and the second
titled "SIP state transition - client". Both of the state transition
diagrams found in the tutorial somewhat differ from the RFC 2543, and
the difference in the titles of the above-mentioned drawings is most
significant. Since neither of the Figures 12 and 13 is either exclusive
or complete with the respect to the INVITE method the titles for the
drawings chosen in the tutorial appear to be better.
It is not a subject of this communication to attempt to explain the
differences found between RFC 2543 and the tutorial. We believe that the
authors of those respective documents are best qualified to resolve
potential discrepancies of the presented graphical representations. We
do however study the issue of call model selection for the Internet
domain.
SIP does explicitly define the notion of "transaction statefulness",
while support for "call statefulness" appears to be implied. This draft
explores the latter concept in some detail.
2.0 Call Model Issues:
Call Model: A Call Model is an abstract representation of user and/or
terminal and/or network expectation built during the process of
establishing, progressing and terminating a call. A call model is most
conveniently represented using the notation of a graphical Finite State
Machine (Moore and Mealy state machines are commonly used).
Following the above definition one can realize that a Call Model can
always be built for two or more logical entities involved in a call and
communicating via a protocol with a well-defined set of messages.
Let us now explore the definition in some detail:
An example of the user expectation is a situation where a callee
expecting a call around 20:00H does not pick the handset at 19:55H
expecting to hear the caller. This expectation is met here through the
process of waiting for some sort of alerting first like: ring, screen
flash, icon, announcement etc.
An example of a terminal expectation is: once a stable call has been
established with no intent to add another party or to change the call
parameters of the existing call, then another INVITE message is not
issued during the call.
An example of a network expectation is that a server does not start
processing the call before the first INVITE message arrives.
As one can observe in the above examples states of a call are of an
intrinsic nature to the communication process and are not associated
with a particular implementation technology.
A more abstract way of looking at the same issue is the realization that
for any two or more entities communicating via a predetermined set of
message sequences (protocol) a Communication Model (Call Model) can be
built.
[Page 2] Call Model for IP Telephony J. Dobrowolski et al.
Expires Dec 2000.
It is important to realize that a Call Model can be implemented on one
or more network physical entities. It is also important to realize that
if a process implementing a portion of a Call Model suspends, storing
state associated with the call, processing may continue on another
network element with the last Call State information available.
An example may be that after a server establishes a stable call leg it
may no longer store the Stable_Call_Leg Call State information. However
if for instance the network uses the RSVP scheme the Stable_Call_Leg
(Active) state might be stored on every selected routing element. It is
also worth noting that the storage of the Stable_Call_Leg state on the
router may require no more that a single bit.
3.0 Discussion:
3.1 The Need for a Call Model:
A Call Model is the agreed-upon least common denominator supported by
different call processing entities within the confines of a distributed
processing network. It consists of abstract events, states and actions.
States are the distinctive "points in processing" where the processing
may be stopped on one server and continued on another server.
Some argue that an alternative approach is possible where the processing
may be stopped at any instruction or even processing cycle. This
"stateless" distributed processing has a number of disadvantages -
primarily a need to keep the identical software and even the identical
software releases on every network server.
The "stateless" approach leads to a coupling between network elements,
that is undesirable in many situations. Such a coupling may cause
interoperability problems while building a network using equipment
provided by different vendors. From the Network Security viewpoint a
stateless model may not be so good if the processing involves entities
belonging to different administrative domains.
It is also very important to realize that the issue of hiding the
network complexity from a Third Party Service Developer is quite
different from the issue of building a new network in the first place.
3.2 The Complexity of a Call Model:
The number of states and transitions is a measure of a complexity of a
Call State Model.
A Call State Model with a higher number of states allows the building of
a richer set of Network Value Added Services (including 3rd party
services) than a low granularity Call State Model with just a few
states. This is a direct consequence of the fact that one has finer
grained control of call-processing in the former case, and more "points
in call" where feature invocation or service access may be supported.
Some software development professionals claim that the Call Model with a
higher number of states is more difficult to implement. This is a small
side effect that arises only when the state machine code is generated
manually. This side effect is by far outweighed by the benefits of the
rich set of services supportable, and can be easily compensated for by
usage of automatic code generation techniques.
[Page 3] Call Model for IP Telephony J. Dobrowolski et al.
Expires Dec 2000.
Even if one generates a State Machine manually, almost every State
Machine implementation consists of double Switch statement, where unused
states are filled with some kind of "No Operation Statements". It is
considered bad practice in telephony implementations to inter-mix Call
State Model code with that for switch-side "features", since this leads
to complicated implementations that are very difficult to test and
expand.
If a given development environment uses automatic code generation
techniques for the Finite State Machine implementation then the number
of states in the model (up to a practical limit of about 60 [3]) does
not really matter from a development stand-point.
3.3 Selecting an IP Telephony Call State Model:
The Internet paradigm derives its strength from a fairly simple and
standardized state model of the basic protocol, namely TCP/IP, with
simultaneous support for non-standardized applications from simple to
very complex. One could argue that the almost ubiquitous nature of the
Internet today is thus a direct consequence of the fact that the base
protocol was built on a standardized state model.
In a similar vein, the accelerated acceptance of IP Telephony would be
greatly facilitated if a single agree-upon call model were supported by
all network call processing elements. It is widely felt that this IP
Telephony Call Model should be fundamentally a superset of existing
telephony Call Models (including the State Machine considerations
presented in the RFC 2543). This is so that one is not constrained by
the limitations imposed by one particular Call Model, while beneficial
features from several of these could be leveraged advantageously during
the process of service access.
If, on the other hand, one were to allow for different/multiple distinct
State Models for use in the IP Telephony domain, every call processing
entity involved in a particular call would be required to support a
"call state model validation phase". Such a validation might also
require a "Call Model negotiation" process during a call establishment,
for every leg of the call in question. This situation is further
complicated when one considers the various services that may be invoked
at any state by any of the call processing entities involved in the
call. A service structure negotiation process could be needed in some
cases as well. (To ensure that when call processing is handed off from
one call-processing element to another, users still get all the features
they subscribed to).
Some service developers present a view that a simple Call Model with a
small set of states is sufficient since they are only interested in
developing a small subset of services, all of which are invoked at
selected supported states only. Such a consideration could be
accommodated by the Service Creation Environment (SCE) that delivers a
subset "view" of the real Call Model that is needed to build a limited
number of services.
[Page 4] Call Model for IP Telephony J. Dobrowolski et al.
Expires Dec 2000.
A simplistic Call Model appears to have clear long-term disadvantages
from the service flexibility and extensibility point of view. Also
inter-working with the existing PSTN services would present problems for
the service developers on the IP as well as the PSTN side, if there is a
significant mismatch in terms of supportable capabilities of the call
models in these two domains.
A Call Model allowing for the creation of a very rich set of network
services is known as an Intelligent Network Call Model. This has been
standardized by ITU-T, and is commonly deployed in telephony networks
today, where it supports access to legacy IN [4] services. We recommend
that this call model be used as a basis for call processing in the IP
domain as well. Interoperation with SIP, H.323 and other protocols could
be easily achieved if appropriate message interfaces were supported for
communications with end-points in the IP domain.
If this process is carried out correctly, one can support simultaneous
access to not only new services possible only in the IP domain, but also
to legacy services from existing telephony networks as well, in a
completely transparent manner. Techniques such as Call Model Integration
[5], and Call Model Emulation [6] may be gainfully employed to achieve
these objectives. [7], for instance shows how these ideas may be used to
support call processing in the SIP domain, with simultaneous access to
services from other domains (such as IN).
4.0 Conclusion:
Support for a multiplicity of Call Models for the IP Telephony domain
would result in difficulties for service development and inter-working,
with the need for pair-wise negotiation and validation of call model
details between call processing entities.
To address these issues, we believe that IP Telephony should have a
single well-defined Call Model that is fundamentally a superset of
existing call models from the telephony domain (including a specially
careful consideration for the State Machine presented in the RFC 2543).
5.0 Security Considerations: This draft addresses general call model
requirements in the IP Telephony domain. Specific security requirements
would have to be addressed by subsequent related drafts that address
related issues.
6.0 References:
1. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
Session Initiation Protocol", IETF Standards RFC 2543, March 1999.
2. H. Schulzrinne Columbia U., "The Session Initiation Protocol SIP"
tutorial, January 18, 2000
3. Ferdinand Wagner, "The Virtual Finite State Machine: Executable
Control Flow Specification." Rosa Fisher-Low Verlag, 1994
4. The Intelligent Network Standards. Their Applications to Services
(McGraw Hill Series on Telecommunications), Igor Faynberg et al,
November 1996.
[Page 5] Call Model for IP Telephony J. Dobrowolski et al.
Expires Dec 2000.
5. Kumar V. Vemuri, Lucent Technologies, "The Call Model Integration
Framework", INTERNET-DRAFT, Work in Progress.
http://search.ietf.org/internet-drafts/draft-vemuri-cmi-framework-00.txt
6. J. Douglas, K. Vemuri, Lucent Technologies, "INSeCT (IN Services for
Converged Telephony)", ICIN2000.
7. Vijay K. Gurbani, Lucent Technologies, "Accessing IN services from
SIP networks" INTERNET-DRAFT, Work in Progress.
http://search.ietf.org/internet-drafts/draft-gurbani-iptel-sip-to-in-01.txt
7.0 Authors' addresses:
Janusz Dobrowolski, Musa Unmehopa,
Lucent Technologies, BE 532
263 Shuman Blvd. Larenseweg 50
Naperville, IL 60566 Postbus 1168
USA. Hilversum, 1200 BD
jdobrowolski@lucent.com Netherlands.
unmehopa@lucent.com
Michel Grech,
Lucent Technologies, Kumar Vemuri,
SIGMA Lucent Technologies,
Optimus Windmill Hill 263 Shuman Blvd.
Business Park Naperville, IL 60566
Swindon, WI SN5-6PP USA.
UK vvkumar@lucent.com
grech@lucent.com
Shehryar Qutub,
Lucent Technologies,
263 Shuman Blvd.
Naperville, IL 60566
USA.
squtub@lucent.com
8.0 Acknowledgments
The authors would like to thank Jack Kozik for interesting discussions
pertaining to ideas discussed in the draft.
9.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). 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."
[Page 6] Call Model for IP Telephony J. Dobrowolski et al.
Expires Dec 2000.
