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