3.3 Inbound Trunks

(Page 4 of 12 in this chapter)
AG Access establishes network-initiated connections for protocols supporting inbound trunks. Once the port's protocol is started, it is eligible to receive incoming calls. After the incoming call event is offered to the application, it is required to either accept the call via adiAnswerCall or reject the call via adiRejectCall.

The general procedure for establishing an inbound connection follows:

Figure 3 contains two protocol timing diagrams; one for answering and one for rejecting an inbound call. The diagrams depict the normal exchange of commands and events between AG Access and the application. Informational events are shown with a dashed line.



: Inbound Call Timing Diagrams

Figure 4 is a state diagram for inbound trunks. The timing diagrams in Figure 3 can be correlated with the state diagram in Figure 4 to gain a comprehensive understanding of the inbound trunk states and events, which are described in the next section.



: Call Control State Diagram - Inbound Trunk

3.3.1 Inbound Trunk Events

This section describes the network events which are generated when establishing inbound connections, as shown in Figure 3 and Figure 4 above:

ADIEVN_SEIZURE_DETECTED - This informational event is generated when a line is seized by the network. Examples of a line-seized event include:

Line Type

Condition

Wink-start

Off-hook detected.

Loop-start

The leading edge of the first ring.

ADIEVN_INCOMING_CALL - This event transitions the port from the idle state to the incoming call state. It is generated after the network delivers the call to AG Access. The following examples illustrate conditions that generate an incoming call event.

Line Type

Condition

Wink-start

All required destination address digits have been delivered to the application.

Loop-start

After a specified number of rings (see loop-start parameters in Appendix D of the AG Access Function Reference Manual).

The application must respond to the incoming call event by invoking either adiAnswerCall or adiRejectCall.

Wink-start protocols require the application to respond within a specified period of time. If the application fails to respond within the given period, AG Access automatically rejects the call and generates an ADIEVN_REJECTING_CALL event. See Section 3.10, Protocol-Specific Parameters, for more information.

ADIEVN_ANSWERING_CALL - After the application invokes adiAnswerCall, this event is generated to acknowledge that AG Access has begun executing the answer call function. Once this event is received, the application transitions to the answering call state.

ADIEVN_CALL_CONNECTED - After the application invokes adiAnswerCall, and receives the ADIEVN_ANSWERING_CALL acknowledgment, AG Access executes the network procedures for accepting the call and establishing the connection. Once the connection is accomplished, the call connected event is generated and the call state transitions to connected.

ADIEVN_REJECTING_CALL - If the application invokes adiRejectCall, the rejecting event is generated once AG Access begins executing the specified reject method. Rejection of incoming calls is protocol-dependent. Loop-start lines can only reject calls by detecting ring indefinitely. Wink-start lines may use one of four methods of call rejection:

The method of rejection is returned back in the value field of the event. The rejecting event is also generated if the application fails to respond to the incoming call event as described above. In this case, the value field will contain host timeout.

ADIEVN_CALL_DISCONNECTED - This event is generated when the calling party disconnects and can occur in any state. The disconnect event contains the reason for disconnect in the value field.

ADIEVN_CALL_RELEASED - After the application invokes adiReleaseCall, AG Access generates the call released event when its internal state is reset to idle.


(Page 4 of 12 in this chapter)

Copyright 1996 Natural MicroSystems, Inc. All Rights Reserved.