Lucent Technologies DEFINITY Enterprise Communications Server Release 5, CallVisor, ASAI Protocol Reference Instructions Manual

							Facility Information Element (FIE) General Description
Issue 6  June 1997
1-5
Facility Information Element (FIE)
General Description
The CCITT Q.932 Facility Information Element (FIE) identifies the capability being 
requested for or responded to within an association.   The FIE carries ASAI 
capability information across the ASAI. At most, one FIE may be contained in a 
REGister, FACility, or RELease COMplete message. All REGister and FACility 
messages contain an FIE. All RELease COMplete messages used during normal 
ASAI operation also contain an FIE. The FIE carries information in a component 
that has one of four basic structures, explained as follows:
1. An Invoke component invokes an ASAI capability and contains: 
nAn invoke-id used to identify this capability’s invocation within the 
ASAI association, and used to associate any later result with the 
specific invocation
nAn Operation Value used to identify the capability
nAny optional ASAI parameters
2. A Return Result component indicates that a previously invoked capability 
(within this association) has successfully completed, and contains:
nThe invoke-id of the FIE that carried the capability request
nAn optional Operation Value that identifies the completed capability3
nAny optional ASAI parameters with a result
3. A Return Error component indicates that a previous ASAI request (within 
this association) is denied, and contains:
nThe invoke-id of the FIE that carried the capability request
nAn Operation Value that identifies the terminated capability
nAny optional ASAI parameters with an error
4. A Reject component rejects a previous FIE that violates protocol, and 
contains:
nThe invoke-id of the rejected FIE (if it can be determined)
nA problem code
3. The optional Operation Value and optional results parameters are both present in or absent 
from the Return Result component. (One is not present without the other.) This is derived 
from Q.932. 
						

							Introduction to Layer 3 Protocol
1-6Issue 6  June 1997 
FIE Acknowledgements
ASAI Capability invocations may be:
The messaging procedures in Chapter 2, ‘‘Messaging Sequences and ASAI’’ 
explain when capability invocations require an acknowledgement. Within an ASAI 
association, an acknowledgement uses the same invoke-id and CRV in the Return 
Result or Return Error component as was present in the invoke request.
An endpoint need not wait for a capability to be acknowledged before invoking 
another capability within the same association. The messaging procedures in 
Chapter 2, ‘‘Messaging Sequences and ASAI’’ indicate when the requesting 
endpoint must wait for acknowledgements. For example, an adjunct may send a 
Third Party Clear Call request at any time during a Call Control association. Also, 
an ASAI endpoint may send an Abort request any time during any association.
FIE Protocol Errors
An ASAI endpoint may use the Reject component to reject a badly structured FIE 
or one that violates protocol. When FIE contents violate protocol, the ASAI 
endpoint may use the Reject component if it is able to determine the message 
type, CRV, and FIE within a message but not where the FIE contents violate the 
protocol. Or, the ASAI endpoint may also abort or return an empty RELease 
COMplete message.acknowledgedThe serving ASAI endpoint always 
responds with either a Return Result 
component or a Return Error component 
(an example is the Value Query 
capability).
unacknowledgedThe serving ASAI endpoint does not send 
a response (an example is the Event 
Report capability).
acknowledged only on failureThe serving ASAI endpoint sends a Return 
Error component if it cannot process the 
request (or if the processing results in an 
error). The serving endpoint does not 
return a Return Result component in 
response to a successful request. 
Examples are the Routing and Third Party 
Make Call capabilities.
acknowledged only on 
successNone of the capabilities supported in the 
ECS ASAI are in this class. 
						

							Facility Information Element (FIE) General Description
Issue 6  June 1997
1-7
ASAI permits the rejecting endpoint to send the Reject component in either:
nA FACility message if the rejecting endpoint permits the requesting 
endpoint to continue the association and retry
nA RELease COMplete message if the rejecting endpoint terminates the 
association when an FIE protocol error occurs
Of these options, the ECS always sends a Reject component in a RELease 
COMplete message to terminate any association where an FIE protocol violation 
occurs. The ECS does not permit the adjunct to retry within the same association 
after an FIE protocol violation.
The ECS does not attempt to retry during any association where an adjunct 
rejects an FIE sent by the ECS. If the ECS receives a Reject component in a 
FACility message, it immediately replies with a RELease COMplete message that 
terminates the association.
Operation Values
As previously noted, each FIE carries ASAI information for an ASAI capability. The 
Operation Value segment of the FIE component identifies the ASAI capability for 
which the FIE is carrying information. The Operation Value/Error Value Coding 
Table in Chapter 4 (Table 4-14 on page 4-48) lists the complete set of Operation 
Values and their encodings.
Invoke-id Values
Invoke-ids are identifiers that carry binary values within each association (CRV). 
To ensure orderly acknowledgements within an ASAI association, endpoints must 
use the following rules to select invoke-ids:
1. With any new request (whether it begins a new association or is one added 
onto an existing association), the requesting endpoint assigns an invoke-id 
value for the duration of that request. Because the invoke-id is a binary 
field, the requesting endpoint may use any binary value except all zeros. 
ASAI reserves the all zero value. In addition, the endpoint initiating the 
ASAI association must use invoke-ids with the low order bit set to one; the 
serving endpoint must use invoke-ids with the low order bit set to zero.
An endpoint making a new request on an existing association need not be 
the endpoint that initially requested the association.
2. Invoke-ids for an association are in one of two states:
nAvailable — Not assigned to an association
nIn-use — Assigned to an association
3. All invoke-ids are available when an association begins. 
						

							Introduction to Layer 3 Protocol
1-8Issue 6  June 1997 
4. When an ASAI endpoint invokes an operation, it uses an available 
invoke-id in the FIE. If the capability is acknowledged, then the invoke-id 
state changes to “in-use.” If the operation is not acknowledged, then the 
invoke-id state remains “available.”
5. An endpoint may assign invoke-id values in any order; they do not have to 
be sequential. Therefore, an endpoint must be able to receive invoke-ids in 
any order.
6. When an ASAI endpoint receives a Return Result or Return Error 
component, the associated invoke-id becomes available.
7. If an adjunct re-uses invoke-ids within a single association, it is 
recommended that it select those ids that have been available for the 
longest period of time.
8. The initiating endpoint must not use (within a given association) the same 
invoke-id value for more than one acknowledged operation at a time. The 
receiving endpoint may reject subsequent requests using an “in-use” 
invoke-id. In other words, the initiating endpoint must ensure that it does 
not use an “in-use” invoke-id when invoking another capability.
Denying an ASAI Request
When an endpoint receives a capability request for a service that is permitted in 
the present ASAI context, but that it cannot provide (such as an invalid value for a 
request parameter), it responds with a message whose FIE contains a Return 
Error component and an optional reason for the denial. The return error response 
must be the first response to the request.
The denial may be carried in:
nA FACility message if the denying endpoint allows the association to 
continue
nA RELease COMplete message if the denying endpoint does not allow the 
association to continue
The ECS expects any adjunct denials to terminate the association. If the ECS 
receives a Return Error component in a FACility message, then the ECS sends a 
RELease COMplete and terminates the association. 
						

							Aborting an ASAI Association
Issue 6  June 1997
1-9
Aborting an ASAI Association
Once an ASAI endpoint has started processing an ASAI request and finds, for 
some reason, that it cannot continue to process the request, the endpoint may 
abort the association. The abort mechanism may be used:
nWhen internal constraints within the ASAI endpoint terminate processing
nWhen a capability request is made on the wrong association
nWhen an error, unexpected, or abnormal condition occurs within the ASAI 
endpoint
Any ASAI endpoint may abort any ASAI association at any time. An ASAI 
endpoint must be prepared to receive an abort at any time.
To abort an ASAI association, the endpoint sends a RELease COMplete message 
containing an FIE with a special Abort Operation Value. The message may 
optionally include a cause. 
						

							Introduction to Layer 3 Protocol
1-10Issue 6  June 1997  
						

							Issue 6  June 19972-1
2
Messaging Sequences and ASAI
This chapter describes the ASAI message sequences for the ASAI capabilities. 
These message descriptions include information necessary for understanding the 
procedures, such as the message direction, message type (REGister, FACility, or 
RELease COMplete), the FIE component type, Operation Value, and the 
parameters within the FIE. 
The descriptions provided in this chapter focus on the information flowing across 
the ASAI. They are not bit-level descriptions of each message. The latter 
descriptions for each message are located in Chapter 5, ‘‘Byte Level Messages.’’
Message Conventions
In this chapter, optional parameters in the message will be enclosed by square 
brackets 
— []. 
						

							Messaging Sequences and ASAI
2-2Issue 6  June 1997 
All procedures implicitly include the denial, association termination, protocol 
violation, reject, and abort messaging.
The message procedures are presented in this chapter in the following order:
nCommon Capabilities (Event Reports)
nCall Control Association
nDomain (Station/ACD) Control Association
nNotification Association
nRouting Association
nRequest Feature Association
nValue Query Association
nSet Value Association
nEnding an ASAI Association
nLink Management and Maintenance
nApplication Timers
Conventions
Within certain messages, specific information elements are optional and may or 
may not be present in a specific message. These items are shown in square 
brackets [ ]. 
						

							Common Capabilities
Issue 6  June 1997
2-3
Common Capabilities
The Event Report capability is common to certain other capability groups that 
require message procedure instructions.
Event Reports
The ECS sends event reports to an adjunct for controlled calls (Third Party or 
Domain) and monitored calls. A call becomes either controlled or monitored in the 
following circumstances:
nThe adjunct invoked a Third Party Make Call capability to set up the call 
(the call is controlled). Event reports are sent on the call control 
association.
nThe adjunct invoked a Third Party Take Control capability to take control of 
the call (the call is controlled). In this case the event reports are sent on the 
call control association.
nThe adjunct invoked the Request Notification capability on a domain and 
the event report pertains to a call that was offered as an incoming call to 
the domain (the call is monitored). The event reports are sent on the 
Request Notification association.
nThe call is present at a station extension for which an adjunct has a 
Domain (Station) Control association. Event reporting for such a call 
ceases when the call leaves the controlled extension (though it may 
continue on another association because it enters a monitored domain or 
arrives at another controlled extension). Event reports are sent on the 
Domain Control Association.
nThe adjunct invoked the Third Party Domain (Split) Control Request for a 
split domain. Event reports inform the adjunct when the agent(s) has 
logged into or logged out of the split domain. The event reports are sent on 
the Domain Control association.
The ECS also sends Charging Event Reports indicating charge advice received 
for ISDN-PRI calls. These are sent if the adjunct has invoked an Event Notification 
capability on the domain of all trunk groups. However these calls are not 
considered monitored by ASAI. No events other than the Charging Event are sent 
on the Event Notification association for all trunk groups.
Certain call-related event reports indicate that further control of a call is no longer 
possible. An adjunct might use this information to determine when it might 
terminate a control association. Event reports are of three types:
1. Those that inform the adjunct of some event; the control association 
continues and adjunct control of the call is still possible.
2. Those that may indicate that no further call control is possible; the only 
additional feedback about this call will be Third Party Call Ended Operation. 
						

							Messaging Sequences and ASAI
2-4Issue 6  June 1997 
3. Call Ended Event Reports, which terminate a Call Control association. 
A RELease COMplete message carries the call ended operation and 
terminates the association. Within a notification association, a FACility 
message carries the Call Ended operation so that the association is not 
terminated and notification of any future calls will continue to occur.
Events may be sent to monitoring, call control, and domain control adjuncts as a 
result of either:
nA manual operation
nA request from another association controlling the call or endpoint
An endpoint making an ASAI call control request receives an acknowledgement, 
not an event report, such as when there is domain control on both stations of a 
call, and one of the associations is used to request a hold. The requesting 
association gets an acknowledgement, and the other association gets a Hold 
Event Report.
All call-related event reports (which 
excludes the Login and Logout Event 
Reports) contain the ASAI call identifier for the call. This identifier specifies the 
particular call the event report is for when the ECS sends event reports for 
multiple calls on a notification or extension control association.