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

							Domain (Station) Control Procedure
Issue 6  June 1997
2-25
If the ECS cannot accept the request, the ECS returns a denial. For coding, 
see ‘‘Domain Control: Request is Denied — Association Continues’’ on 
page 5-90 of Chapter 5, “Byte Level Messages.”
3. Various sequences of event reports and adjunct requests for call control 
may occur. In terms of the message procedure, the event reporting and call 
control are a sequence of FACility messages flowing across the interface.
Third Party Answer Procedure
An adjunct may use the Third Party Answer capability within an existing Domain 
(Station) Control association to answer a call at the controlled extension. Use of 
this capability with certain types of stations (including analog) may require user 
action (going off-hook before a timer expires) for station set types that the ECS 
cannot take off-hook remotely.
1. The adjunct sends a FACility message on an existing station control 
association. The message contains:
an invoke FIE, 
an invoke identifier, 
Operation Value=Third Party Answer, 
and parameters for: 
the call identifier (Call Identifier IE).
2. If ECS provisioning permits the ECS to accept the Third Party Answer 
request and the ECS successfully completes the request, then the ECS 
sends a FACility message to return a successful result. The message 
contains:
a return result FIE with: 
Operations Value=Third Party Answer, and 
the invoke-id from the request.
3. If the ECS cannot complete the request, the ECS returns a denial. For 
coding, see ‘‘Domain Control: Request is Denied — Association 
Continues’’ on page 5-90 of Chapter 5, “Byte Level Messages.” 
						

							Messaging Sequences and ASAI
2-26Issue 6  June 1997 
Call Control Procedures
Once the adjunct has control of a third party call, within either a Call Control or 
Domain (Station) Control, it may invoke various call control capabilities.
The adjunct passes the CRV for the Call Control or Station Control association in 
the FACility message containing these capability requests.
If the ECS denies any of these requests, a FACility message carries the denial so 
that the call control association continues. Certain parameters are shown as 
optional; their use depends on whether the call is being controlled over a Call 
Control association or a Domain (Station) Control association:
nThe call_id should not be included in requests on Call Control associations 
since such an association controls only one call. If an adjunct should 
include a call_id in such a request, the ECS will ignore the call_id. The 
call_id must always be included in requests on Domain (Station) Control 
associations since such an association may control more than one call at 
an extension.
nThe party_id should not be included in requests on Domain (Station) 
Control associations since such an association controls only one endpoint 
on the call. If an adjunct should include a party_id in such a request, the 
ECS will ignore the party_id. The party_id must always be included in 
requests on a Call Control association since such an association may 
control more than one party on a call.
Third Party Drop Procedure
The adjunct requests that the ECS drop a party from a call that this ASAI 
association controls.
1. The adjunct sends the ECS a FACility message containing an invoke FIE 
with:
Operation Value = Third Party Selective Drop and 
[a party to be dropped from the call] (Party ID IE), or 
[the call being controlled] (Call Identity IE), 
[User-to-User Information] (User-User IE), and 
[drop tones (Resource Identifier IE)
7]. 
For call control coding, see ‘‘Third Party Selective Drop Request’’ on page 
5-45 of Chapter 5, “Byte Level Messages.” For domain control coding, see 
‘‘Third Party (Domain) Selective Drop Request’’ on page 5-72 of Chapter 5, 
“Byte Level Messages.”
7. Permitted on Call Control only. Not allowed on Domain Control. 
						

							Call Control Procedures
Issue 6  June 1997
2-27
2. The ECS drops the party and replies with a return result FACility message. 
The invoke-id in the return result has the same value as the invoke-id in the 
third party drop request. For call control coding, see ‘‘Call Control: 
Acknowledgment (No Parameters) Association Continues’’ on page 5-61 of 
Chapter 5, “Byte Level Messages.” For domain control coding, see 
‘‘Domain Control: Acknowledgment (No Parameters) Association 
Continues’’ on page 5-89 of Chapter 5, “Byte Level Messages.”
Third Party Hold Procedure
The adjunct requests that the ECS put a call on hold with respect to a given party.
1. The adjunct sends the ECS a FACility message containing an invoke FIE 
with:
Operation Value = Third Party Hold and 
[a party for which the call will be placed    
on hold] (Party ID IE), or 
[the call being controlled] (Call Identity IE).
For call control coding, see ‘‘Third Party Selective Hold Request’’ on page 
5-46 of Chapter 5, “Byte Level Messages.” For domain control coding, see 
‘‘Third Party (Domain) Selective Hold Request’’ on page 5-73 of Chapter 5, 
“Byte Level Messages.”
2. The ECS puts the call on hold and replies with a return result FACility 
message. The invoke-id in the return result has the same value as the 
invoke-id in the Third Party Hold request. For call control coding, see ‘‘Call 
Control: Acknowledgment (No Parameters) Association Continues’’ on 
page 5-61 of Chapter 5, “Byte Level Messages.” For domain control 
coding, see ‘‘Domain Control: Acknowledgment (No Parameters) 
Association Continues’’ on page 5-89 of Chapter 5, “Byte Level Messages.”
Third Party Reconnect Procedure
The adjunct requests that the ECS reconnect a party to a call that this ASAI 
association controls.
1. The adjunct sends the ECS a FACility message containing an invoke FIE 
with:
Operation Value = Third Party Reconnect, and 
[a party for which the call will be reconnected] (Party ID IE), or 
[the call being controlled] (Call Identity IE).
For call control coding, see ‘‘Third Party Reconnect Request’’ on page 5-47 
of Chapter 5, “Byte Level Messages.” For domain control coding, see 
‘‘Third Party (Domain) Reconnect Request’’ on page 5-74 of Chapter 5, 
“Byte Level Messages.” 
						

							Messaging Sequences and ASAI
2-28Issue 6  June 1997 
2. The ECS reconnects the party to the call and replies with a return result 
FACility message. The invoke-id in the return result has the same value as 
the invoke-id in the third party reconnect request. For call control coding, 
see ‘‘Call Control: Acknowledgment (No Parameters) Association 
Continues’’ on page 5-61 of Chapter 5, “Byte Level Messages.” For domain 
control coding, see ‘‘Domain Control: Acknowledgment (No Parameters) 
Association Continues’’ on page 5-89 of Chapter 5, “Byte Level Messages.”
Third Party Merge Procedure
The adjunct requests that the ECS merge two calls controlled by an ASAI 
association or associations. Both calls have a party in common. Prerequisite to 
requesting a merge, the adjunct must place a call on hold with respect to the 
common party. After a successful merge, the ECS sends an acknowledgement on 
the call control association over which it received the merge request.
1. The adjunct, using the same association that was used to put the call on 
hold, sends the ECS a FACility message containing an invoke FIE with:
Operation Value = Third Party Merge, and 
[the party that is common with respect to the held call (Party ID IE)], or 
[the held call (Call Identity IE)], 
the call_id that refers to the other call (Call identity IE), and 
an indication of whether the merge is a conference or transfer 
(Conference/Transfer IE).
For call control coding, see ‘‘Third Party Merge Request’’ on page 5-48 of 
Chapter 5, “Byte Level Messages.” For domain control coding, see ‘‘Third 
Party (Domain) Merge Request’’ on page 5-75 of Chapter 5, “Byte Level 
Messages.”
2. The ECS replies with a return result FACility message containing:
Operation Value = Third Party Merge, 
a call identifier for the resulting call
8 (Call Identity IE), 
a list of up to six old party identifiers (Old Party-ID IE), 
a list of up to six party identifiers for the parties on the call (Party ID IE), 
and a list of up to six extensions of the parties on the call
(Connected Number IE). 
The invoke-id in the return result has the same value as the invoke-id in the 
Third Party Merge request. For call control coding, see ‘‘Acknowledgment 
of Third Party Merge Request’’ on page 5-59 of Chapter 5, “Byte Level 
Messages.” For domain control coding, see ‘‘Acknowledgment of Third 
Party Merge Request (Domain)’’ on page 5-87 of Chapter 5, “Byte Level 
Messages.”
8. The call identifier may be different from the call identifiers for the calls being merged. The 
ECS/adjunct uses this new call identifier for the merged call in all subsequent event reports 
and other interactions. 
						

							Call Control Procedures
Issue 6  June 1997
2-29
Adjuncts receiving event reports for the calls involved in the Third Party Merge 
receive an acknowledgement, Transfer Event Report, Conference Event Report, 
or Call Ended depending on the role they played in the merge, the type of merge, 
and what they are monitoring.
Third Party Clear Call Procedure
The Third Party Clear Call capability may be used only in Call Control 
associations and may not be used in Third Party Domain (Station) Control 
associations. The adjunct requests that the ECS disconnect all parties on a call.
1. The adjunct sends the ECS a FACility message containing an invoke FIE 
with:
Operation Value = Third Party Clear Call.
For call control coding, see ‘‘Third Party Clear Call Request’’ on page 5-44 
of Chapter 5, “Byte Level Messages.”
2. The ECS sends a RELease COMplete acknowledgement containing a 
return result FIE with the invoke-id in the acknowledgement having the 
same value as the invoke-id in the Third Party Clear Call Request. For 
coding, see ‘‘Call Control: Acknowledgment — Association Terminates’’ on 
page 5-63 of Chapter 5, “Byte Level Messages.”
Send DTMF Signals Procedure
The adjunct requests that DTMF tones be sent on a call to selected parties.
1. The adjunct sends the ECS a FACility message containing an invoke FIE 
with:
Operation Value=Send DTMF, 
call on which the tones are to be sent (Call Identity IE), 
[a list of up to five parties that will hear the DTMF tones] (Party ID 
IE), 
the DTMF tones (User Data IE), 
[tone duration] (Call Options IE), and 
[pause duration] (Call Options IE).
For call control coding, see ‘‘Third Party Send DTMF Digits Request’’ on 
page 5-52 of Chapter 5, “Byte Level Messages.” For domain control 
coding, see ‘‘Third Party (Domain) Send DTMF Digits Request’’ on page 
5-80 of Chapter 5, “Byte Level Messages.”
2. The ECS sends the DTMF tone and replies with a return result FACility 
message. The invoke-id in the return result has the same value as the 
invoke-id in the send DTMF request. For call control coding, see ‘‘Call 
Control: Acknowledgment (No Parameters) Association Continues’’ on 
page 5-61 of Chapter 5, “Byte Level Messages.” For domain control 
coding, see ‘‘Domain Control: Acknowledgment (No Parameters) 
Association Continues’’ on page 5-89 of Chapter 5, “Byte Level Messages.” 
						

							Messaging Sequences and ASAI
2-30Issue 6  June 1997 
Redirect Call Procedure
Starting with G3V4, the Redirect Call procedure includes the following sequence 
of messages:
1. The ECS sends the adjunct a FACility message with an invoke FIE 
containing:
Operation Value = Redirect Call, 
[the party the call is redirected from] (Party ID IE), 
the number that the call is redirected to (Redirection Number IE), and
[the call_id of the call to be redirected] (Call Identity IE).
For call control coding, see ‘‘Redirect Call’’ on page 5-54 of Chapter 5, 
“Byte Level Messages.” For domain control coding, see ‘‘Redirect Call 
(Domain)’’ on page 5-82 of Chapter 5, “Byte Level Messages.”
2. The ECS redirects the call and replies with a return result FACility 
Message. The invoke-id in the return result has the same value as the 
invoke-id in the Redirect Call request.
For call control coding, see ‘‘Call Control: Acknowledgment (No 
Parameters) Association Continues’’ on page 5-61 of Chapter 5, “Byte 
Level Messages.” For domain control coding, see ‘‘Domain Control: 
Acknowledgment (No Parameters) Association Continues’’ on page 5-89 of 
Chapter 5, “Byte Level Messages.”
Third Party Listen Disconnect Procedure
NOTE:
Third Party Listen Disconnect capability may only be used in the Third Party 
Call Control Associations and may not be used in the Third Party Domain 
(Station) Control associations.
The adjunct requests that the ECS selectively disconnect a party (a listener) with 
respect to a given party or parties [a talker(s)].
1. The adjunct sends the ECS a FACility message containing an invoke FIE 
with:
Operation Value = Third Party Listen Disconnect,
 a party which will be listen-disconnected (the listener)
 (Party ID IE), 
 [a party from which the listener is disconnected (the talker)
(party ID IE)].
For coding, see ‘‘Third Party Listen Disconnect Request’’ on page 5-50 of 
Chapter 5, “Byte Level Messages.” 
						

							Call Control Procedures
Issue 6  June 1997
2-31
2. The ECS listen-disconnects the call and replies with a return result FACility 
message. The invoke-id in the return result has the same value as the 
invoke-id in the Listen Disconnect request. For coding, see ‘‘Call Control: 
Acknowledgment (No Parameters) Association Continues’’ on page 5-61 of 
Chapter 5, “Byte Level Messages.”
Third Party Listen Reconnect Procedure
NOTE:
Third Party Listen Reconnect capability may only be used in the Third Party 
Call Control Associations and may not be used in the Third Party Domain 
(Station) Control associations. 
The adjunct requests that the ECS selectively reconnect a party (a listener) with 
respect to a given party or parties [talker(s)].
1. The adjunct sends the ECS a FACility message containing an invoke FIE 
with:
Operation Value = Third Party Listen Reconnect, 
a party which will be listen-reconnected (the listener)
 (Party ID IE),
[a party from which the listener is disconnected (the talker) 
(Party ID IE)]
.
For coding, see ‘‘Third Party Listen Reconnect Request’’ on page 5-51 of 
Chapter 5, “Byte Level Messages.”
2. The ECS listen-reconnects the call and replies with a return result FACility 
message. The invoke-id in the return result has the same value as the 
invoke-id in the Listen Reconnect request. For coding, see ‘‘Call Control: 
Acknowledgment (No Parameters) Association Continues’’ on page 5-61 of 
Chapter 5, “Byte Level Messages.” 
						

							Messaging Sequences and ASAI
2-32Issue 6  June 1997 
Notification Association Procedure
An adjunct can request that the ECS supply event reports over three types of 
domains: ACD splits, Vector Directory Numbers (VDNs) and trunk groups. The 
ACD split domains cannot be administered as controlled splits or vector-controlled 
splits. The event reports provide the adjunct with call related information.
The event reports for these domains all contain a call identifier that associates 
call-related event reports with specific calls.
1.  The adjunct sends a REGister message to begin a notification association.
The message contains an invoke FIE with:
Operation Value = Request Notification, and 
the split or VDN domain (Domain IE).
For coding, see ‘‘Event Notification Request’’ on page 5-98 of Chapter 5, 
“Byte Level Messages.”
2. The ECS sends a FACility message to acknowledge the request. The 
message contains a return result FIE. The invoke-id has the same value as 
the invoke-id in the notification request. For coding, see ‘‘Notification: 
Acknowledgement (No Parameters) Association Continues’’ on page 5-101 
in Chapter 5, “Byte Level Messages.”
3. The ECS sends appropriate event reports to the adjunct via FACility 
message.
4. If, during the normal course of event reporting, the adjunct needs to 
terminate the event reporting for any given call within the notification 
association, the adjunct may send a FACility message. The message 
contains an invoke FIE with:
Operation Value = Stop Call Notification and 
a call identifier for the call (Call Identity IE).
For coding, see ‘‘Stop Notification on Call Request’’ on page 5-100 of 
Chapter 5, “Byte Level Messages.”
a. If the call_id is valid, then the ECS stops notification for this call 
within the Notification Association and sends an ACK to the adjunct. 
The ACK is a return result FACility message. The invoke-id in the 
return result has the same value as the invoke-id in the Stop 
Notification request. For coding, see ‘‘Notification: 
Acknowledgement (No Parameters) Association Continues’’ on 
page 5-101 in Chapter 5, “Byte Level Messages.”
b. If the call_id is not valid, the ECS returns a FACility containing a 
Return Error component and a cause.
Stop Call Notification is not supported on the Notification association for the 
domain of all trunk groups. 
						

							Notification Association Procedure
Issue 6  June 1997
2-33
5. If, during the normal course of event reporting, the ECS has reason to 
terminate the event reporting (such as the domain being administered out 
of existence), the ECS sends a RELease COMplete message to terminate 
the association. The message contains an invoke FIE with:
Operation Value = Notification Ended and 
a cause (Cause IE).
For coding, see ‘‘switch Ends Notification Reporting Association’’ on page 
5-105 of Chapter 5, “Byte Level Messages.”
6. To terminate the event reporting association, the adjunct sends a FACility 
message continuing an invoke FIE with:
Operation Value = Cancel Notification.
For coding, see ‘‘Cancel Event Notification Request’’ on page 5-99 of 
Chapter 5, “Byte Level Messages.”
a. The ECS acknowledges the cancel with a RELease COMplete 
message containing a return result FIE. The invoke-id in the return 
result has the same value as the invoke-id in the Cancel Notification 
Request.
For coding, see ‘‘Notification: Acknowledgement (No Parameters) 
Association Terminated’’ on page 5-103 of Chapter 5, “Byte Level 
Messages.” 
						

							Messaging Sequences and ASAI
2-34Issue 6  June 1997 
Routing Association Procedure
The ECS can ask the adjunct to supply a route for an incoming call.
1. The ECS sends a REGister message containing an invoke FIE with:
Operation Value = Route, and
parameters containing [CPN/BN] (Calling Party Number IE
or Trunk Identification),
9 
the dialed number (Called Party Number IE),
the call identifier for the call to be routed (Call Identity IE), 
the VDN making the route request (Domain IE),
10 
[PRI Lookahead Interflow information] (Lookahead Interflow IE), 
[digits collected by the ECS prompter] (User Code IE), 
[User-to-User Information] (User-User IE),
[originating line information] (Originating Line IE), and
[flexible billing] (Feature IE).
For coding, see ‘‘Call Route Request’’ on page 5-109 of Chapter 5, “Byte 
Level Messages.”
The ECS does not use the ASAI 
return_ack flag. The adjunct does not 
return an acknowledgement to the ECS on receipt of the routing request; it 
sends a route when one is available.
If the vector step following the route step is not a WAIT or 
ANNOUNCEMENT or ADJUNCT ROUTE, the ECS goes to the next Step 
and sends a Route End to the adjunct to terminate the Routing association.
See the 
Adjunct/Switch Application Interface (ASAI) Specification, 
555-025-203, for more details.
2. The adjunct responds with one of the following:
a. If the adjunct accepts the routing request and returns a route, it 
responds with a FACility message containing an invoke FIE with:
Operation Value = Route Select, 
a route for the call (Called Party Number IE), 
[the origination number] (Calling Party Number IE), 
[option for a priority call] (Call Option IE), 
[option for a direct agent call] (Call Option IE), 
[Trunk Access Code necessary for external routing] (Domain IE), 
[ACD Split extension] (Domain IE)
11, 
9. The ECS supplies the data that the network has passed to the ECS with the incoming call: 
CPN or BN, but not both. The Calling Party IE is present when the calling number is known; 
it is mutually exclusive with the Trunk Identification IE which is present when the number is 
not known.
10. This is typically the dialed number. However, if an initial VDN (with routing) directs the call 
to a second VDN (also with routing), then the dialed number is the first VDN and the 
Domain IE contains the number of the second VDN when it requests a route.
11. Present if and only if direct agent call option is also present. If the ACD split extension and 
the direct agent call option are present, the called number must contain a physical 
extension in the EAS environment.