Professional Telco Programming

May 18th, 2010Posted by Steve

So you have looked at TAPI and messed around with telephone calls, you ask yourself how hard can professional telco programming be? The simple answer is "pretty hard" and its nothing like the consumer version TAPI.

The first thing that you need to understand to program telco grade software is the concept of a state machine, ninety nine perrcent of the telco systems rely upon this architecture.Switchboard The odd programmer has experimented with state machines but it is not a popular subject. The essence of state machines is that state is preseverd only up to the last action that was taken and no more. This signifies that the only information available to perform a command is that which is passed back in the response to the previous command. The reason for this becomes apparent when programming professional telephone systems, due to the volume of calls every byte counts forget memory gobbling session variables they wont work. Programming a state machine is not too difficult and involves a main loop that always feeds to one central method or handler containing all of the logic concerning the actions to be performed. One of the best solutions although seldom used are actually event handlers.A high level view of a state machine using event handlers would look something like the following;

while (true)
    // Recieve Request
    // Fire the Event Handler passing the information on;

private void OnRequest(object sender, EventArgs e)
    // Interpret Request
    // Send Acknowledgement

Now you know what a basic state machine is, how do you identify each individual call?. In telco systems each call is identified by a Span and a Channel which can be compared to a grid usually the spans are the "X" axis with the channels being "Y". This information will be passed in the request to perform an action. The communication between the switch and the controlling machine is conducted using messages and acknowledgement messages or "MESSAGE" and "ACK" over a socket connection. At this point it is prudent to point out that telco Switches are "dumb" pieces of hardware and every action you perform has to be programmed in a language it understands namely hexadecimal. No high level languages here not even 3gl, never mind 4gl. By now you may be beginning to get the picture, there is a significant difference between TAPI and commercial systems, what you must do is actually write the API itself to control the switch. If all of this is not bad enough, to be classified as "carrier grade" it must have a five 9's uptiime thats 99.999% guaranteed uptime, be totally redundant and lightning fast.

So what do these messages look like, how do you go about designing such a system? The simple answer is that there are only a few rules the rest is upto you. The basics are that for a message to perform a command it must first translate the users requirements ensuring that the basic information is passed along with the message The API will then translate the message into machine language send it to the hardware and read the current state. This information is then turned back into a response and sent back to the user as an acknowledgement message. If you are still with me, let's take a look at designing a real system.