Internet Engineering Task Force Internet Draft Kumar Vemuri draft-vemuri-cmi-framework-00.txt Lucent Technologies January 20, 1999 Expires: June 20, 2000 Category: Informational Call Model Integration Framework 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 In this paper we study the problem of call model integration. Several call models are in common use. Most are customized for efficiency of operation and ease of access to features within specific domains. Access to features external to a given domain may be facilitated by overlaying the call model representation intrinsic to said external domain atop the base call model integral to the pre- specified base domain. 1.0 Introduction: Let us begin by defining some basic terms for use in the discussions that follow. o A domain is an instance of a type of network. o A base domain is the network that supports access from end-points being served. A base domain may also provide certain services. o A services/external/foreign domain is the target network whose services it is desirable to provide to the network end-points within the base domain. o A Call Model is a finite state machine that governs/controls the execution of a call, how a call progresses, what features/ services may be accessed, and at what call states. K. Vemuri Internet Draft [Page 1] Call Model Integration Framework o Call Control Elements (CCE's), Service Switching Elements (SSE's) etc., are generic elements that embody the functions associated with the corresponding elements from the IN architectural specification [1]. Different domains support different services, or even the same service in a different way. Sometimes it makes better sense to access existing services from a foreign domain rather than re- implement said services within the context of the base. This is especially true when one requires access to a large body of existing features from the foreign domain. If, on the other hand, one needed very few features from the foreign domain, or required access to a large number of foreign features from a large number of different external domains (but only a few from each of these external domains, a somewhat even distribution), one could consider re-implementing the features within the context of the base for better performance characteristics while keeping implementation costs low. A peculiar set of issues need to be addressed when one tries to bridge two domains together in order to achieve total service transparency across different access modes. The most important of these is "call model integration" which is studied in detail in the rest of this paper. 2.0 Call Model issues: A call model in the most general form consists of three basic functional components: a. the Call Control Element - that handles call processing related functions, b. the Service Switching Element - that handles all service access related functions (where features are hosted off of other network entities), and c. the Feature Interaction Manager Element - that resolves conflicts in feature access and execution. (a) and (b) are embodied within a Finite State Machine (FSM), that tracks the flow of control as call processing proceeds. These are the components of greatest interest here. In this paper, we will ignore (c) since the feature interaction problem is extremely complex, has no general solution, and several books have been written on that very topic. Every entity that processes calls possesses these elements in some form. The "call model integration" issue arises because the base domain has its own FSM representation of these elements, as does the external domain of interest, and one needs to be able to interface/integrate the two so that while new services are made available to base-domain end-points, the base call model is not constrained in strange or unusual ways, and that no base services break once foreign services are made accessible. It is also K. Vemuri Internet Draft [Page 2] Call Model Integration Framework desirable that the foreign call model implementation supported is general enough to ensure easy access to a large number of foreign services, not just a small sub-set. Different services are triggered at different states within the context of a given call, some within the base domain, and some without. It is therefore essential to be able to maintain a unified view of call state across the two domains so that a. service logic is triggered at the appropriate points in the call, and b. the state required by the external (foreign domain) server providing the service can be maintained within the context of the base call model in some form. (b) is important when one considers the fact that though there might be two different call models executing in lock-step, one representing the base domain, and the other the foreign domain of interest, they should always share a common call state so that one has a unified view of the call. This implies that states from one call model must be semantically mapped into the other. It often happens that the two call model FSMs do not have the same number of states, therefore a plurality of states from one FSM may map into a single state in the other or vice-versa. However, state boundaries are preserved in mappings. (In other words, a state mapping from one FSM to another does not straddle state boundaries in either FSM). This concept is clarified by the adjoining schematic. +--+ +--+ +--+ +--+ +--+ FSM A |P |-----|Q |-----|R |-----|S |-----|T | +--+ +--+ +--+ +--+ +--+ | \ \ \ | \ \ | \ \ \ | \ \ +--+ \ +--+ \ +--+ \ +--+ \ +--+ \ +--+ FSM B |G |-----|H | ----|I |-----|J |-----|K |-----|L | +--+ +--+ +--+ +--+ +--+ +--+ one to many one to one straddling states P to both G,H Q to I R to J, S to both J and K many to one (permitted) (not permitted) both R,S to J (permitted) One to many mappings are permitted, typically from the FSM with fewer states, to one with a larger number of states. Many to many mappings are not permitted where two connected states, (one from each FSM) have one-to- many relationships. (e.g., S and J above). Figure 1: Call Model Mappings. Straddling state boundaries is not desirable since it causes the mapping procedure to become more complicated (state S from FSM A is split up across J and K, but state J also has other functionality K. Vemuri Internet Draft [Page 3] Call Model Integration Framework that results from the mapping of R into J, thus handling the states J in FSM B and S in FSM A, will be difficult since there is no one state that corresponds to either from the other FSM. One needs to look at J at a finer level of granularity to determine a functional mapping to a part of state S from FSM A (the rest maps to K). This is a problem we seek to avoid in our construction). If such a mapping does result, and is un-avoidable, state S can be split up into two states S1 and S2, with a transition between the two states in the original FSM, with S1 corresponding to J and S2 to K in FSM B. The resulting simpler mapping is semantically equivalent to the original, more complex one. This is illustrated in Figure 2. +--+ +--+ +--+ +--+ +--+ +--+ FSM A |P |-----|Q |-----|R |-----|S1|-----|S2|-----|T | +--+ +--+ +--+ +--+ +--+ +--+ | \ \ \ | | | | \ \ \ | | | +--+ \ +--+ \ +--+ \ +--+ +--+ +--+ FSM B |G |-----|H | ----|I |-----|J |-----|K |-----|L | +--+ +--+ +--+ +--+ +--+ +--+ Figure 2: Simplifying complex call model mappings. These call model mappings function under a set of constraints - the base call model receives events from end-points in the base domain, and reacts to them, while the foreign call model representation serves mainly as a "service accessor" and reacts to service requests and responses generated. As noted above, both these elements possess the capability to influence call processing, and share information through a shared data structure. +-----------------+ | foreign service | +-----------------+ \ \ +-----------------+ \ | base service | \ +-----------------+ +-------------+ / | foreign SSE | / +-------------++-------------+ call model ---> | foreign CCE || base SSE | integration --> +-------------++-------------+ | base CCE | +----------------------------+ Figure 3: "Call Model Integration". If one is to effectively implement this operation of the two call model FSMs in lock-step, one has to ensure that when the base call model makes a transition from one state to another, the FSM associated with the foreign call model makes an analogous transition and vice-versa. K. Vemuri Internet Draft [Page 4] Call Model Integration Framework In addition, if the base call model implements a SSE in some form, as does the foreign call model FSM (we know the foreign call model FSM has an SSE because the reason we're interested in call model integration in the first place is because we're trying to get at services in the foreign domain, and that requires a service triggering mechanism implemented in an SSE), we must ensure that triggering of service requests is carefully implemented and that there are enough rules to govern the invocation/execution of services since one would like to avoid feature interactions between/across domains if at all possible. Example: FSM A is in state S2 which implies FSM B is in state K. Now FSM B receives an event that causes a state transition to state J (let us assume such a state transition is permitted). This state change by FSM B causes FSM A to transition to state R (since R corresponds to the beginning of state J in FSM B). Please also note that some FSM transitions cannot be easily supported. For example, FSM B cannot be permitted to transition from state H to state H (state-loop) since this will require an intra- state transition in FSM A. (This can be done in software, but the result is not as elegant as it could have been). If one does indeed want to support such transitions elegantly, one could re-structure FSM A and break up state P into two states P1 and P2, each of which has a direct one to one correspondence relationship with a single state from FSM B. Note however that this construction is not required if said transition is not supported. 3.0 "Call Model Integration": One may view this process more abstractly as the mapping between nodes of two different graphs (with not necessarily a one-to-one relationship between nodes in the two graphs). For purposes of this discussion, a node in the graph is a state in the call state machine, and an arc or an edge is a connection that reflects the transition from one state to another. Input to the upper graph/FSM results in state transitions there from one node to another via arcs in that graph. This REQUIRES (in general terms where there are no transitions between states that are all mapped to the same state in the other FSM - a state transition from state R to state S1 in FSM B of figure 2 for example, requires no corresponding state transition be made in figure 1) the movement of the state in the lower graph to the node that corresponds to the new node in the upper graph, independent of whether or not there is a path between the said two nodes in the lower graph. (there generally is, if the mapping is done right, but we must allow for the case where there isn't a path). Similarly, when input is received by the lower graph and acted upon, an analogous transition is required in the upper graph. The state machine that results from the process of "integration" may be constructed by the following procedure: K. Vemuri Internet Draft [Page 5] Call Model Integration Framework Let us say event E (an event in the base domain), causes a state transtition from A to B in the base domain states, and forces the foreign call model to go to state Z. Now, if the base domain FSM is in state A, the foreign domain state machine can presumably only be in some set of states, say set Y (probably this is usually one state). Now, what happens is that event E causes the foreign FSM to go from states in Y to Z on event E. So, just add an edge to the foreign state machine, from each state in Y, to Z, with edge event E. The result in the foreign domain is a single state machine, with events from both the base domain FSM and the foreign domain FSM, but states only from the foreign domain. The result in the base domain (when the same procedure is followed with suitable modifications), is a single state machine, with events from both the base domain FSM and the foreign domain FSM, but states only from the base domain. These two state machines are completely semantically equivalent though they may appear to be different, and result from the mapping process. The first presents a better service level perspective while the second presents a more complete description of occurrances within the base domain. The two together influence call processing, and can share a unified view of call state by sharing appropriate call state information. 4.0 Event Processing: Processing of events is easy to describe when only one of the two FSMs involved in call processing receives an event. However, this cannot always be guaranteed. One can define a precedence relationship between the different kinds of events that either FSM can receive given its current state, and also establish a precedence among the FSMs themselves. For example, given the set-up of figure 2, if FSM A is in P and FSM B is in H, and FSM A receives events and while FSM B simultaneously receives event , there must be rules specified when the mapping is done to a. state which FSM is permitted to process events first, b. what order those events might be processed in, c. whether and what state transitions are permitted on each of those events, and d. whether the synchronized state machine can process events too, what events it can process, and in what order. This permits one to have a reasonably well-defined set of transitions when events are asynchronously received. A couple of exceptions may be cited. These are by no means the only ones that exist, but are indicative of some of the complexities that need to be addressed when the process of call model integration is carried out: K. Vemuri Internet Draft [Page 6] Call Model Integration Framework Transitions in state machines could result from messages being received from external entities. Consider the case where two state machines FSM_A and FSM_B are tightly integrated. Now, a transition from state M1 to M2 in FSM_A is typically caused by the receipt of a message from an external source. However, states N1 and N2 in FSM_B map to states M1 and M2 in FSM_A, and a transition from N1 to N2 in FSM_B is supported. Now, when FSM_B makes a transition from N1 to N2, FSM_A is REQUIRED to make the corresponding transition from M1 to M2, even without the receipt of the message in question. Thus, things might not always work when this happens (the message contains information required for further processing that we do not now have). The same applies if the transition from M1 to M2 requires that a message be sent out to some external entity as the transition is being made, as part of typical FSM_A operation, when certain FSM_A- based state transition criteria are met. However when FSM_A is constrained to make this transition as a result of state changes in FSM_B, after these two FSMs have been integrated, one needs to decide a. whether there is enough information in FSM_A for it to generate the message that it would have sent out under normal (independent) operational conditions, and, b. if such a message does indeed need to be sent given the current call context that bridges the two domains in question. Issues of this nature need to be considered carefully and addressed on a case-by-case basis. 5.0 Alternatives to Call Model Integration: An outcome similar to that achieved through this complex process of state machine synchronization may also be achieved through the insertion of the appropriate triggering mechanism (for services hosted by the foreign domain), into the base call model itself. However, it must be realized that while this solution would work in some (or even most) cases, the lack of separation between the two call domains (say IN and IP) would result in a complex piece of code that would not lend itself easily to being extended to support newer and more complex services. In general terms, one can state that the solution as described above (the one involving call model integration) is probably maximally efficient from the design standpoint (though not from the performance perspective) since it is easily extensible to support more services, service logic access is neatly separated from device-related call handling, and data that is needed for call completion and service invocation is clearly partitioned. When the call model integration approach is used, as more foreign domain services are added, one needs to make smaller and smaller changes to the foreign domain call model layer code (since one only has to arm the trigger and provide a message format for communication with the server in the foreign domain that provides the service being accessed). Compare this with the other alternative where call handling becomes more and more complicated as more services are K. Vemuri Internet Draft [Page 7] Call Model Integration Framework supported. Add to this the complexities of arming and disarming triggers on a per call basis, based on the context defined by the calling and called parties, and the complexity increases significantly. Another point in favor of call model integration may be cited if one considers the fact that certain services in the foreign domain might not be supportable in a simple request-response fashion, and might require the support of a state machine in some form in the foreign call model. This would be difficult to do if the alternative to call model integration was used in the implementation. This is not to say there is no merit to the other implementation. If better performance is sought, and one need support only a smaller set of simple services, and adding triggers to foreign services from the base domain does not adversely impact access to services within the base domain itself, the other solution would probably be the preferred implementation. It must be realized though, that as the solution evolves to support more services, a point would be reached where it would have been more efficient to implement access to foreign domain services as we have described. 6.0 Applications: The contents of this draft loosely define a framework within whose context one can build integrated service/access systems. An example of its application would be a system that supported access to IN services from IP (H.323 or SIP) end-points. Here, the base domain would be IP(H.323) or IP(SIP) and the services domain would be IN, and some network component (a soft switch of sorts) could implement the mapping of call states between the two FSMs under consideration (the FSM that corresponds to the IN call states, and the FSM associated with the base protocol). In other words, soft switch (SSP) design and implementation is a domain where this idea could be applied advantageously. [2] and [3] explore this issue in greater detail within the context of specific domains. K. Vemuri Internet Draft [Page 8] Call Model Integration Framework +-------+ | SCP | +-------+ | Figure 4: TCAP/IP | Call Model Integration example. interface | +--------------+ This figure depicts the | | IN call | integration of the base H.323 +--| model layer | protocol state machine with the +--------------+ IN call model state machine. If | H.323 | such a system were to be | protocol FSM | constructed, IN services could +--------------+ be made accessible to IP end- / \ -points. / \ +--------+ +--------+ | H.323 | | H.323 | | client | | client | +--------+ +--------+ 7.0 Conclusion: Call Model integration is an effective and efficient means of extending service support to end-points in any given domain. Based on the degree of commonality between them, in terms of state machine and call processing similarities, some call models might be easier to integrate together than others. 8.0 Security Considerations: Security considerations do not apply directly to the general domain of Call Model Integration, though one could require that all events generated be verifiable for authenticated identities of their respective senders etc., Specific implementations of mappings between different domains might have their own requirements, which must be satisfied. Those requirements must be stated and studied in greater detail in drafts that focus on specific mappings. 9.0 References: [1] The Intelligent Network Standards: Their Application to Services (McGraw Hill Series on Telecommunications) by Igor Faynberg (Editor), Marc P. Kaplan, Nitin Shah, Lawrence Gabuzda, November 1996. [2] IN Technology for Internet Telephony Enhancements, draft-dobrowolski-iptel-in-00.txt, Janusz Dobrowolski et al., Lucent Technologies. [3] Accessing IN services from SIP networks, draft-gurbani-iptel-sip-to-in-00.txt, Vijay Gurbani, Lucent Technologies. K. Vemuri Internet Draft [Page 9] Call Model Integration Framework [4] IN Services for Converged Telephony, Janet Douglas and Kumar Vemuri, ICIN 2000. 10.0 Acknowledgements: The author would like to acknowledge comments made by Jonathan Rosenberg that led him to a deeper understanding of issues in this domain, and especially for comments that formed the basis for the construction algorithm for call model integration, and part of the "event processing" discussion. The author would also like to thank John Stanaway, John Voelker, and Igor Faynberg for comments that helped improve the quality of the discussion. 11.0 Authors' Addresses Kumar V. Vemuri, 1A-415, P.O. Box 3050, 263 Shuman Blvd., Indian Hill Park, Naperville, IL 60566-7050. USA electronic mail: vvkumar@lucent.com K. Vemuri Internet Draft [Page 10] Expires: June 20,2000 Call Model Integration Framework