Computer Supported Telecommunications
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
Secretariat for further disposition.
Questions on Protocol,
Tools, and Others.
Modelling and architecture
- How does the CSTA application relate
to the Computing and Switching functions, and also to a telephony
- Does CSTA assume that a telephony driver
exists or do we have to make some changes in our switch to support
- What is the "CSTA Link"
between the switch and a server?
- Why does the MakeCall service
in ECMA-217 show the caller connected to a call before the service
Protocol and syntax
- How does my company get object
- Where can I find the description
of the OPERATION asn1 macro with (ARGUMENT , RESULT, ERROR and
CODE) used in Phase III
- Why is the heading "( iso(1)
......, icd-ecma(0012).... make-call(10) )" defined in
the protocol (example for Make-call service(ecma-218)?
Behaviour and features
- Is it possible to conference an inbound and an outbound call using Conference Call service?
- Are event sequences standardized in CSTA?
- May a Connection Cleared
event with LocalConnectionInformation = NULL be sent ONLY when
the phone goes on-hook?
- How do I use CSTA from an "IVR
- How do I clear an incoming
call before it rings?
- How can I detect when a POT phone
is able to make a call?
- How can CSTA Routeing be used?
- Why does my SNACC compiler
complain about not finding a security IMPORT module when compiling
- How can I redefine the XML-schema
definition of ConnectionID to prevent the " Element Particle
Validation error " of Xerces?
- Do we have to support all the
switching functionality defined for CSTA, to be compliant?
- How will CSTA evolve?
- Is there a source file for ECMA-218 to input into ASN.1 compilers ?
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.
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 184.108.40.206 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,
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.
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/220.127.116.11 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
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
- 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
- Corrigendum 1 X.882 (11/95), ISO/IEC International Standard
13712-3: "Technical Corrigendum to ITU-T Recommendation
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
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
The bibliography includes citations
of the official specifications of ASN.1, and a tutorial explaining
ASN.1 and the Basic Encoding Rules.
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
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
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
To be CSTA compliant do we have to support
all the switching functionality defined for CSTA?
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.
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
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?
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
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
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.
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
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 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:
- As determined by the switch configuration, redirect the call
to some device (e.g. operator) in the switch.
- Request a destination from the computing domain, which it
does by using CSTA.
As a typical example for CSTA assisted routeing of an incoming
- 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.
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).
How will CSTA evolve
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.
How to prevent the Xerces " Element
Particle Validation " error when parsing ConnectionID instances?
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
<xsd:element name="deviceID" type="csta:LocalDeviceID"/>
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
- 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
- [ASN1-A] "Introduction to ASN.1 and the Packed Encoding
- [ASN1-B] "Abstract Syntax Notation One",
freeware ASN.1 compiler in C/C++.
freeware ASN.1 compiler in Java.
Updated 11 December 2008