Activities |
|
 |
 |
 |
|
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
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
Protocol and syntax
Behaviour and features
Application
Tools
Miscellaneous
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: 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:
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:
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:
However the following sequence is valid too:
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. 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. 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."
Use http://www.oid-info.com/get/1.3.12.2 to add your company in the Ecma Object IDentifiers (OIDs) branch. 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.
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. 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. 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. 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. 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 prefixing How to clear an incoming call before it rings A developer writes: 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. Why does my SNACC compiler complain about not finding a security IMPORT module when compiling from ECMA-218? A developer writes: 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:
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? Answer 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):
How can CSTA Routeing be used? Answer: When an incoming call comes into a switch it can be handled in one of 2 ways:
As a typical example for CSTA assisted routeing of an incoming PSTN 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 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. How to prevent the Xerces " Element Particle Validation " error when parsing ConnectionID instances? 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">
Bibliography
Updated 11 December 2008 |
|
||
|
|