Appendix A

Call Models

A.1 Introduction

A call model is a generic and abstract representation of switch-based call-processing activities required to set-up, maintain, and tear down a call. Call models can be quite complicated, especially for unsuspecting consumers who just pick up the phone to call their friends and family. In a now-expired IETF Internet Draft [Dobrowolski 2001] explaining the need for call models, and how these may be used, the authors use a simple children’s toy (two cans connected by a string) as an example to motivate the discussion, and then derive a call model from it.

Excerpt [Dobrowolski 2001]

We explain the concept of a call model in very simple terms, using the example of a ‘two cans, one string’ model that small children play with, to communicate. This model consists of two cans A and B that each have a small hole drilled at the bottom. A thread or string is then pulled through the holes connecting the cans together, and knotted on the inside. We embellish this simple model with a bell being fastened to each of these two cans.

Operation is simple. The two cans are placed on two tables. Alice (aged 8) wants to call Bob (aged 7). She picks up one of the cans, and tugs lightly at the string. Bob’s phone moves, and the attached bell rings. Bob picks up his can and (assuming the string is taut) conversation commences. Eventually, one of them puts their can down, and the ‘call’ is terminated.

This very simple example illustrates several very important aspects of a call model and the finite state machine associated with a call. Even though this is very minimal in scope, it still supports several states. For instance:

  1. Initially both cans are on their respective tables. No call exists. This is the NULL or IDLE state.
  2. Alice picks up the phone. She has just ‘gone off-hook’ (of course, there is no dial tone, and no dialing of digits).
  3. Alice tugs lightly at the cord. Similar to ‘Call Sent’ in some of the existing telephony call models.
  4. Bob’s can ‘rings’. ‘Alerting’.
  5. Bob answers the phone, and conversation ensues. ‘Call Active’.
  6. Alice or Bob places their can back on the counter. ‘Disconnected’.

Admittedly, this is a very simplistic model. In practice, however, more states would be added in order to allow for the creation of classes of applications that could be possibly implemented. But the basic concept of the Call Model remains the same. The above example shows that the mutually agreed-to call model exists with simple state machines (agreed-upon procedures) ‘executed’ by the callee (Bob) and caller (Alice). This is also an indication that the call model is a higher level of agreement (more fundamental) than protocol or signaling.

The authors also use this simple model to investigate other aspects of the call-related finite state machine, more specifically called a BCSM or a Basic Call State Model. Even a simple model can give us sufficient basis for making discoveries about some things, and show us how tweaks to certain aspects may or may not change overall behavior while enhancing or degrading the end-user experience [Dobrowolski 2001].

Excerpt [Dobrowolski 2001]

Let’s assume that tugging the cord was replaced with raising a hand. This would be an example of retaining the same Call Model and the same Finite State Machine while changing the signaling. Now let’s assume that Bob always keeps the can next to his ear and ignores the tug on the string (Bob is eager for Alice’s call after all). This would change the call model and the state machines. Signaling (tugging) would not be affected while becoming somewhat redundant (not really needed).

Here, the call model state machines are (logically) executing within the minds of the two communicating parties. They monitor external behavior (signaling), and determine what actions are required of them to make the communication work. Once these simple actions are carried out, communication commences. In real networks it is the finite state machine that executes on every node on the network that satisfies user, network, and endpoint expectations with respect to signaling interactions during call setup, processing, stable state, possible roaming state in a wireless network, and tear-down. It should be noted that though the finite state machines executing on different network nodes may be different, the most consistent user experience results when the state machines comply with the same call model.

Figure A.1 An example call model (network perspective)

Simpler models are easier to manipulate, but they may not be able to simulate the behavior of all aspects of the real world. Unless the ignored aspects are critical to a particular analysis, simplifying assumptions help rather than hurt the modeling exercise. For instance, the ‘two cans and string model’ does not cover aspects of service control from Intelligent Networks, but this is not a major drawback since the focus here is the call model, not feature assist.

In reality, it is not reasonable to expect that all switches in a network execute exactly the same call model, though they will be largely alike. For one thing, networks tend to be true multi-vendor environments, with each vendor’s switch having its own peculiarities.

We also emphasize that it is important to understand the limitations of models before we employ them. The can and string example is a good one to communicate ideas relating to basic call models, finite state machines, and call processing, but is not nearly sophisticated enough to be able to model services like conference calling. For instance, only two parties are supported. Simplicity in modeling contributes to easy (or easier) understanding of complex systems, but building simple models that simulate the characteristics of the system under study is not always easy. A model may be simple, but not easy to derive, and a simple model may be easy to understand in relation to the real system only in hindsight.

A.2 IN Capable Call Models

From the foregoing, it is clear that a call model consists of a set of states and models call processing on a switching element within the telecommunications network. They may be of different types. For example, ‘Half-call’ call models tend to have two FSMs, one for the originating side of the call, another that models the terminating side of the call. ‘Dialing’ is typically an operation related to the originating side, whereas ‘ringing’ is typically a terminating side occurrence (after all, the caller dials the callee’s phone number, and the callee’s phone rings). This kind of distinction between the two sides is often also beneficial in designing or distinguishing services as originating and terminating side services – e.g. originating service could be outgoing call barring, whereas terminating could be Call Forwarding on Busy. As an example, one such call model, defined for IN CS-2 (Capability Set 2) by the ITU-T, is depicted in Figures A.2 and A.3, for the originating model and terminating model respectively [Q.1224 1997].

Figure A.2 Originating BCSM for IN CS-2 [Q.1224 1997]

Figure A.3 Terminating BCSM for IN CS-2 [Q.1224 1997]

Call models support a set of transitions between the various states (any decent FSM should), and a set of conditions for these transitions. The states are called ‘Points In Call’ or PICs. So far, it is just another FSM.

Next, they have elements called Detection Points or DPs between states, at the state ingress points (in some models, these are drawn at egress points). DPs are specialized structures – they can each host zero, one, or more triggers. PICs and DPs are clearly visible in the IN CS-2 call model. Collect_Info, Analyze_Info, etc., are examples of PICs (large rectangles representing states in call processing). Collected_Info, Analyzed_Info, etc., that are representative of points where trigger processing may occur (denoted by smaller rectangles), are examples of Detection Points.

Triggers have conditions associated with them, and can be armed, or not. When these triggers are armed, and conditions are met during call processing, they ‘fire’. This results in a message (populated with current, related parameters for the call being processed) being sent to another network element called a Service Control Point or SCP, requesting further instructions. When the SCP executes service logic and returns a response, the switch that originated the request processes this response, and then uses this new information in further call processing. (See Figure 1.1 from Chapter 1.)

Triggers are classified into different types based on how they are provisioned, and also on what happens when they fire. For example, triggers may be:

  1. Statically provisioned via a provisioning system (Service Management Function or SMF); or
  2. Dynamically armed during call processing by the SCP (dependent on certain state changes).

DPs that house the former kind of triggers (Type 1 from the above list) are referred to as Trigger Detection Points or TDPs. Where triggers may be dynamically armed (Type 2), the SCP may send back a response to the switch requesting that it be notified when certain events occur. DPs that house this second type of triggers are typically referred to as Event Detection Points or EDPs. For example, in response to a request from a switch, an SCP may send back a message asking to be notified when a busy or no answer condition occurs later on during call processing.

When a trigger fires, the switch may either

  1. Suspend all call processing activity associated with that call and wait for the response from the SCP; or
  2. Send a notification to the SCP, and continue on with call processing, to use the SCP response as it becomes available.

The triggers of Type (a) are hosted by DPs called DP-Rs (R for Request), while DPs hosting triggers of Type (b) are called DP-Ns (N for Notification). Thus, DPs can be of four types (looking at Types 1, 2 and (a), (b) together) – TDP-R, TDP-N, and EDP-R and EDP-N.

Default treatment is defined at the switch to be able to deal with scenarios when the SCP or signaling network to the SCP become unavailable for whatever reason, so that call processing requirements are always met. This may imply that value added services are not executed, but failure in some service logic does not adversely affect the basic call. As shown in Chapter 1, this is one of the benefits of separating switching logic from service logic in IN.

References

[Dobrowolski 2001] Dobrowolski, J. and Vemuri, K., ‘Internet-based Service Creation and the Need for a VoIP Call Model’, draft-dobrowolski-voip-cm-01.txt, IETF Internet Draft, Expired (May 2001). A copy can be downloaded from URL:

[Q.1224 1997] ITU-T Recommendation Q.1224, Telecommunication Standardization sector of ITU, Series Q: Switching and Signalling, ‘Distributed functional plane for intelligent network Capability Set 2’, September 1997