Avaya UCID - Demystified

Avaya UCID consists of three parts:

1) Node ID (N)

2) UCID - Sequence number (S)

3) Timestamp (T)

Node ID (N): A number between 1 and 32767. It is a unique number to identify the switch in the network that generated the call.

UCID - Sequence number (S): A number between 1 and 65535. This number uniquely identifies the call in a given node.

Timestamp (T): This time is the number of seconds since epoch (midnight 1 Jan, 1970) at the time of call origination.

UCID Format

Format of UCID is : NNNNNSSSSSTTTTTTTTTT

Where N stands for Node ID, S for UCID-Sequence number and T for timestamp.

CM generated UCID for all calls originating at the switch. If UCID exists for an incoming call, CM stores the UCID without any modification. For incoming calls without UCID, the switch generate a UCID for the call. For calls spanning multiple switches, the UCID is sent along with call information during call setup scross the network (which would imply PRI with QSIG).

Example: Assume a call has the following information stored in its call record

Node ID: 21; UCID - Sequence Number: 5; Timestamp: 946085673

The generated UCID in ASCII format will be: 00021000050946085673

TAPI vs. TSAPI

TAPI is a telephony API developed by Microsoft, TSAPI is a telephony API developed by the company that eventually became Avaya (AT&T -> Lucent -> Avaya). TAPI's design was oriented torward first party call control (i.e. phones), while TSAPI was oriented torward third party call call control (i.e. PBXes and central office switches). TAPI does have some limited support for dealing with the call audio, TSAPI has none. I'd be very surprised if you could find a TAPI TSP for Avaya AES, and you won't be getting it from Avaya if you do.

If all you're interested in is call events, then you can do the same things with both APIs, but the code will be totally different. Most companies that have products that have to talk to both Avaya AES and Cisco Call Manager have created an generic CTI interface for their product and then write code modules (aka drivers) that translate the TSAPI and TAPI call events to their generic event format. In your case, depending on your OS, you can move your TAPI code into a separate DLL/shared library, then create a separate DLL/shared library that implements the same functions but using TSAPI instead of TAPI.Frotunately, a lot of the smaller PBX manufacturers use either TAPI or TSAPI based APIs for their CTI interfaces, so if you have to connect to a third PBX, chances are good that you can reuse one of the two modules.

The 3 Laws of Robotics

When I think of robots or androids, only one stands out in my mind; Data from Star trek Next Generation. Data exhibited humane behavior and, as per Asimov’s definition, was a ‘positronic’ robot. He latently followed the three laws of robotics, penned by Asimov many decades ago. These laws were,

1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey any orders given to it by human beings, with the exception of orders conflicting with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.


Most people are familiar with these laws but what many do not know is that, in Asimov’s own words these laws were analogous to the design of any valuable tool. He postulated,

1. A tool must be safe to use.
2. A tool must perform its function efficiently unless this would harm the user.
3. A tool must remain intact during its use unless its destruction is required for its use or for safety.


In one of his short stories (Evidence), Asimov explained the moral grounding behind these laws. He stated that human beings are generally expected to refrain from harming other human beings (except in times of extreme duress; like war, or to save a greater number). This is equivalent to a robot's First Law. Likewise, society expects individuals to obey instructions from recognized authorities (such as doctors), which equals the Second Law. Finally, humans are generally expected to avoid harming themselves, which is the Third Law.

In the recent decade, technology has come a long way and scientists are in the process of actually setting forth a Robot Ethics Charter. This document would be heavily influenced by the three laws but there is sufficient criticism for them out there to think twice.
Modern experts tend to agree that the Laws are perfect for a good story line but present practical problems. According to them the first law is flawed as it states that a robot cannot 'through inaction, allow a human to come to harm'; it should be noted that a robot has finite knowledge and if anything which harms a human is not in its data bank it will invariably end up harming a human. Further when humans harm humans (e.g. in case of war or accidents); the laws would imply that robots end up taking charge of humanity, in an effort to prevent humanity from harming itself.

The above criticisms aside, robots are a very distinct possibility of the future and there are those who feel some ground rules should be set. In the July/August 2009 issue of IEEE Intelligent Systems, Robin Murphy and David D. Woods proposed "The Three Laws of Responsible Robotics":

1. A human may not deploy a robot without the human-robot work system meeting the highest legal and professional standards of safety and ethics.
2. A robot must respond to humans as appropriate for their roles.
3. A robot must be endowed with sufficient situated autonomy to protect its own existence as long as such protection provides smooth transfer of control, which does not conflict with the First and Second Laws.


The above three laws are also suggestions. No matter what ground rules are set, they will have to be updated and improved constantly as technology progresses. Some day we may have creations which follow the idealistic 3 Laws of Robotics, but for now we will have to contend with the practicalities of the philosophy and the limitations of our technology.