Computer Supported Telecommunications Applications (CSTA)

Frequently Asked Questions

Altough the answers to the following questions do not represent an official Ecma International position, they might ease using and implementing the standard. Please don’t hesitate to contact the Ecma Secretariat for further disposition.

Questions on Protocol, Features, Application, Tools, and Others.

Modelling and architecture

How does the CSTA application relate to the Computing and Switching functions, and also to a telephony server?

This picture, which depicts one example, may make the situation clearer:

The bottom of each stack, whether it is in the switching domain or computing domain, is a transport layer. The top of the computing domain is an application. By some means, typically an API, the application generates CSTA PDUs encoded as defined by ECMA-218, to invoke the services of ECMA-217. In the switching domain, there is a call control function that performs the services of ECMA-217, which it receives as ECMA-218-encoded PDUs.

Currently, CSTA doesn’t specify these stacks, other than ASN.1 encoding/decoding (that is, the application and presentation layers) and the semantics of “Call Control Function”.

Does CSTA assume that a telephony driver exists or do we have to make some changes in our switch to support CSTA?

Unless your switch is CSTA ready, you will have to probably do one or both of these. Your switch will have to be able to have an ASN.1 encoding/decoding layer for CSTA, and have a transport layer that will communicate to the client over the “switch link”. On the client side, you will need to provide similar functions. This may be done via a driver, but that is an implementation detail.

What is the “CSTA Link” between the switch and a server?

The above figure should cover this – it is a transport layer between a client and the server. It could be a serial cable, a LAN, the Internet, whatever you provide in your switch.

Why does the MakeCall service in ECMA-217 show the caller connected to a call before the service is used?

At first sight it may not seem logical to have the call connected before using the MakeCall service, which you would expect to create the call. However, the condition of having the call already connected is an option, the connection may exist or it may be Null (because the call doesn’t yet exist). We need to allow for the call to exist to allow for cases where MakeCall is allowed whilst the phone is off-hook and providing dial tone, e.g. for manual number prefixing

Protocol and syntax

For private data CSTA requires that “Manufacturer specific (or standard) extensions shall be uniquely identified using Object identifiers issued by Ecma according to ISO 6523.” How do I get such an Object identifier?

Use http://www.oid-info.com/get/1.3.12.2 to add your company in the Ecma Object IDentifiers (OIDs) branch.
Once registered your company becomes responsible for issuing OIDs under their own naming node.
The need to check that an identifier does not already exist within the company cannot be stressed too much. The authority may charge “a reasonable fee” for this service.

Where can I find the description of the OPERATION asn1 macro with (ARGUMENT , RESULT, ERROR and CODE) used in Phase III (ECMA-269). I can’t find the CODE definition in ROSE X219 / X229)

ECMA-269 uses the 1994 ROSE specification, published as ITU-T Recommendation X.880 and as ISO/IEC International Standard 13712-1.
Other documents that may be of interest are:

  • ITU-T X.880 (7/94), ISO/IEC 13712-1: “Remote Operations: Concepts, Model and Notation”
  • Corrigendum 1 X.880, ISO/IEC International Standard 13712-1: Technical Corrigendum 1
  • ITU_T X.881 (7/94), ISO/IEC International Standard 13712-2: “Remote Operations Service Element (ROSE) Service Definition”
  • Amendment 1 X.881 (11/95), ISO/IEC International Standard 13712-2: “Amendment 1: Mapping to A-UNIT-DATA and Built-In Operations”
  • X.882 (7/94), ISO/IEC International Standard 13712-3: “Remote Operations Service Element (ROSE) Protocol Definition”
  • Amendment 1 X.882 (11/95), ISO/IEC International Standard 13712-3: “Amendment 1: Mapping to A-UNIT-DATA and Built-In Operations”
  • Corrigendum 1 X.882 (11/95), ISO/IEC International Standard 13712-3: “Technical Corrigendum to ITU-T Recommendation X.882”

Why is the heading “( iso(1) ……, icd-ecma(0012)…. make-call(10) )” defined in the protocol (example for Make-call service(ecma-218)?

What you are looking at is an ASN.1 definition of the protocol data unit (PDU) for the Make Call service. ASN.1 is “Abstract Syntax Notation One”, a data structure representation methodology developed by the International Telecommunications Union (ITU). It consists of a declarative language (the header is written in ASN.1, for example), and an agreed-upon set of encoding rules for translating the ASN.1 source code into a byte stream. The syntax and encoding rules allow protocol developers to guarantee that they are encoding and decoding the byte streams the same way. Standards organisations such as Ecma, ITU, ISO develop protocols that have very complex PDUs, and in general multiple protocols may coexist on the same transport, so ensuring that the byte streams can be recognised correctly is very important.

To use the definition of MakeCall in ECMA-218, for example, you must write code that encodes a MakeCall command into a byte stream according to the ASN.1 definition (this code runs in your application stack), and code that decodes the MakeCall byte stream (this code resides in your switch) into an internal data structure that your switch can interpret and execute. For “simple” pieces of ASN.1, this can be done by manual compilation, much like translating a fragment of C into object code. But for complex ASN.1 definitions, this can become very difficult. For example, the fragment:

( iso(1) ……, icd-ecma(0012)…. make-call(10) )

is an object identifier, a byte stream that encodes the Make Call command uniquely among all possible commands from all possible sources from all possible standards (whew!) . The ISO (i.e., iso(1)), Ecma (i.e., icd-ecma(0012), etc., tags uniquely identify this command as being defined by Ecma and nobody else. To compile this manually, you need to find the ASN.1 definitions that define the header, and apply the so-called Basic Encoding Rules (BER) to translate it. Among the definitions you will need are ROSE (Remote Operation Service Element) and ACSE (Association Control Service Element), which are defined in other standards documents (see the Bibliography).

There are some developers who either know ASN.1 very well, or are only using a very few PDUs, who write encoding and decoding functions manually. Most people use ASN.1 compilers, which take ECMA-218, ROSE, ACSE, etc. definitions as input, and generate encoding and decoding functions (in your favourite programming language) as output.

ASN.1 was defined in the early 1980’s (documents X.208, X.209), and updated in 1994 to include such features as Unicode encoding (X.680, X.690). CSTA Phase II and CSTA Phase III assume the 1994 definition.

The bibliography includes citations of the official specifications of ASN.1, and a tutorial explaining ASN.1 and the Basic Encoding Rules.

Behaviour and features

Is it possible to conference an inbound and an outbound call using Conference Call service?

Yes, it is. There are no preconditions regarding the directions of the two calls that are target of the Conference Call service.

However, there are preconditions regarding the local connections states of the calls at the conferencing device. The connections shall be either:

  • One in Connected and one in Hold state
  • Both in Connected state
  • Both in Hold state

If these preconditions are not met, e.g. because the local connection state of the inbound call is Alerting (or Queued) then the required initial states can be reached, e.g. as follows:

  • The Computing Function may use the Alternate Call service to place the outbound call on hold and answer the inbound call. This may be suitable for scenarios where the called party wants to talk privately with the caller to inform him that he is going to be placed into a conference before actually conferencing him. (Usually the caller would not expect to end up in a conference when calling a device that belongs to a single person).
  • The Switching Function may implicitly answer the inbound call (auto answer). This may be suitable if the called device is for instance a conferencing device (i.e. a conference bridge) that auto-answers all incoming calls to play an announcement or ask for authentication.
  • The Computing Function may use the Answer Call service to answer the inbound call. This may be suitable for scenarios where the caller expects to end up in a conference and it’s not desirable to put the already existing call on hold (e.g. if the called party is not a person’s phone but a conference device).

Other combinations that may additionally involve Hold Call and/or Retrieve Call services are also possible.

Additionally, there may be scenarios where the Conference Call service isn’t even necessary since the called device answers and conferences the inbound call implicitly (auto-answer and auto-conference).

Are event sequences standardized in CSTA?

Event sequences are standardized within a monitor in CSTA. However, CSTA does not mandate to fire the events associated to the completion criteria before acknowledging a service request. It only mandates that the events are being fired (at some time).  Generally, CSTA does not mandate that:

  • events of different monitors are synchronized between the monitors or
  • events of a monitor and responses to requests are synchronized

When e.g. a MakeCall is positively acknowledged within the atomic acknowledgement model the completion criteria have been reached within the SF. Therefore, the following sequence is valid:

  • MakeCall Request
  • [Service Initiated Event] (optional)
  • Originated Event
  • MakeCall Response

However the following sequence is valid too:

  • MakeCall Request
  • MakeCall Response
  • [Service Initiated Event] (optional)
  • Originated Event

ECMA TR/82 may be a little misleading in respect to that topic, since service requests (and their responses) are shown  in the column of Monitor 1 instead of an own column that indicates its sequential independence.
Because CSTA does not guarantee the sequence of events across different monitors or between events and responses, clients that keep a state are generally recommended to update their call model based on the events on a single monitor only.
However, services that query a concrete state (e.g. Snapshot Services) need to be synchronized with the events.

Should a Connection Cleared event with LocalConnectionInformation = NULL be sent only when the device goes on-hook?

This does not need to be the only case, a device can be in the NULL state whilst being off-hook. A connection cleared event with the LocalConnectionInformation = Null can be generated when a call on hold is cleared at a device (in other words the other party cleared the connection).

Application

How do I use CSTA services and events from an IVR script?

CSTA features, especially Call Control features, can certainly be used with scripting. For example, ECMA-323 (CSTA XML) messages can be used with scripting languages such as ECMAScript to create very powerful environment for IVR applications.

You can see examples of how this is used in the SALT 1.0 specification that was recently published by the SALT Forum (http://www.saltforum.org/ ). Section 2.6.6.2 of the specification shows how ECMAScript is used with CSTA XML (ECMA-323) to perform the following: listen for an incoming call, answer it, play some voice prompts to the caller, take actions based upon the voice recognition results from the caller, and transfer the caller to another destination, etc.

The Ecma CSTA group plans to continue work in the future to improve the usefulness of CSTA for voice enabled applications in different types of environments.

How to clear an incoming call before it rings

A developer writes:

I have a question concerning the timing between the switching domain and the application domain. The following example might help to illustrate the question:

Assume that there is an incoming call to a local device of the switching sub-domain and that the device is monitored by an application. The switching function will generate a “DeliveredEvent” according to the CSTA standard and will deliver this event report to the application domain. Now, assume that the application wants – for whatever reasons – to prevent the called device from being alerted. The problem is that the application only discovers that the device is about to get a call when it receives the event and hence cannot issue a “ClearCall” request until this occurs, meanwhile the switching domain could already have started alerting the device.

Is there any way to allow the application to get in and stop the call before the device is alerted?

Answer:

In phase I and phase II of CSTA you will have to use the Routeing Services to intercept the call and re-route it to an alternative device where it may be cleared after it has started to alert the alternative device.

However, there is a new call control event, called Offered, in ECMA-269 (CSTA Phase III) that may provide a better solution to your problem. If supported on the device by the switching function, the Offered event is generated when the call arrives at the device but before the device is alerted. Typically the device stays in this “offered” state until it receives instructions from an application on what to do with the call (CSTA service requests like Divert Call, Accept Call, or Clear Connection, for example) or, in the absence of any such instructions, after a certain (switch determined) time period the device would typically be alerted.

We think that this may provide the switch/application synchronisation that you are looking for as it will allow the application an opportunity to clear the call before the device is alerted.

For more information refer to the Offered event and the Accept Call service in ECMA-269.

How can I detect when a POT phone is able to make a call?

Generally going on-hook/off-hook activates/deactivates the auditory apparatus of the device and there is no direct relationship to the connection states of that device.

To find out if an analogue phone is free for a call then (assuming that the application is not already tracking the device):

  • Snapshot to find if it is currently in a call
  • Query device to ensure not in DND etc.

How can CSTA Routeing be used?

When an incoming call comes into a switch it can be handled in one of 2 ways:

  1. As determined by the switch configuration, redirect the call to some device (e.g. operator) in the switch.
  2. Request a destination from the computing domain, which it does by using CSTA.

As a typical example for CSTA assisted routeing of an incoming PSTN call:

  • Switches can be configured so that incoming calls on selected trunks are sent by the PBX (without CSTA assistance) to a routeing device (e.g. a special queue). When calls arrive at the routeing device this triggers the switch to initiate a CSTA Routeing Dialogue with the CSTA application on behalf of the call (using the routeSelect service). The purpose of the CSTA Routeing Dialogue is to enable the CSTA application to indicate to the switch a suitable destination for the call from the routeing algorithm in the computer application.
  • If the switch fails to find a suitable destination within a time set for the switch then the switch takes back the control of the routeing of the call.

Tools

Why does my SNACC compiler complain about not finding a security IMPORT module when compiling from ECMA-218?

A developer writes:

My SNACC compiler complains about not finding a security IMPORT module when compiling from ECMA-218

Answer

The “Security-Information” module and definitions are part of ECMA-219 “Authentication and privilege attribute security application with related key distribution functions”, using the ASN.1 specification from this standard the missing code can be added for the PrivilegeAttributeCertificate symbol.

However, ECMA-219 implies some development on each client/server side. If the implementer does not want to use these features, they can simply define the missing type as:

PrivilegeAttributeCertificate ::= NULL.

You may also have found that the UTCTime value is unresolved, this should be included in the SNACC compiler using the usefull.asn1 file (see the SNACC documentation).

Finally it should be noted the server is not supposed to send security information if the client doesn’t ask it to.

How can I redefine the XML-schema definition of ConnectionID to prevent the ” Element Particle Validation error ” of Xerces?

Answer:

Xerces complains about having to read ahead to establish the type of the Call-ID part of ConnectionID. The following definition of ConnectionID doesn’t require the parser to use ” look ahead “:

<xsd:complexType name="ConnectionID">
<xsd:choice>
<xsd:element name="deviceID" type="csta:LocalDeviceID"/>
<xsd:sequence>
<xsd:element name="callID" type="csta:CallID"/>
<xsd:element name="deviceID" type="csta:LocalDeviceID" minOccurs="0"/>
</xsd:sequence>
</xsd:choice>
</xsd:complexType>

Miscellaneous

Do we have to support all the switching functionality defined for CSTA, to be compliant?

No. There is a PICS Performa (a sort of template) at the end of the protocol in ECMA-218. A switch manufacturer may provide a PICS statement describing what functions they provide.

How will CSTA evolve?

Answer:

To ensure backwards compatibilty, CSTA will add Services, Events and optional Parameter values, while retaining existing.

Is there a source file for ECMA-218 to input into ASN.1 compilers ?

We suggest taking the WORD version of ECMA-218 and extracting the ASN.1 source from this file.

Bibliography

  • ISO 6523 Data interchange — Structures for the identification of organizations (1984)
  • ISO/IEC 7498-1 International Standard: Information Processing Systems – Open Systems Interconnection – Basic Reference Model
  • ISO/IS 8649 International Standard: Information Processing Systems – Open Systems Interconnection – Association Control Service Element
  • IS/ISO 8824 International Standard: Information Processing Systems – Open Systems Interconnection – Specification Of Abstract Syntax Notation One (ASN.1) (This corresponds to CCITT X.208, which was updated in 1994 to X.680)
  • IS 8825 International Standard: Information Processing Systems – Open Systems Interconnection – Specification Of Basic Encoding Rules For ASN.1 (This corresponds to CCITT X.209, which was updated in 1994 to X.690)
  • DIS 9072-1 Draft International Standard: Information Processing Systems – Text Processing – Remote Operations Part 1: Model, Notation And Service Definition
  • DIS 9072-2 Draft International Standard: Information Processing Systems – Text Processing – Remote Operations Part 2: Protocol Specification
  • [ASN1-A] “Introduction to ASN.1 and the Packed Encoding Rules”,
  • [ASN1-B] “Abstract Syntax Notation One”,
    http://renoir.vill.edu/faculty/schragge/html/CSC8560/asn1.html
  • SNACC: freeware ASN.1 compiler in C/C++.
  • SNACC: freeware ASN.1 compiler in Java.

Updated 11 December 2008

Back