Package com.avaya.conferencing.api.acp.control.events

Avaya Conferencing Provider Interface Events.

See:
Description

Interface Summary

AvailableVerbsChangeListener<S extends ConferencingObject<S>>	A listener for AvailableVerbsChangeEvents.
ChildListener<P,C>	A listener for ChildEvents.
ConferenceEndPointListener	A listener for EndPoint instances joining and leaving Conference instances.
ConferenceListener	A listener for Conference instances starting and stopping on the connected Avaya Conferencing Provider Connection.
ConferenceQueueListener	A listener for Conference instances joining and leaving a ConferenceQueue.
ConferencingObjectQueueListener<Q extends ConferencingObjectQueue<Q,E>,E extends ConferencingObject<E>>	A listener for entries being added to, reordered within or removed from ConferencingObjectQueues.
DTMFListener	A listener for DTMFEvents.
EndPointQueueListener	A listener for EndPoint instances joining and leaving a EndPointQueue.
SourceSequentialEventListener	A marker interface for event listeners that will ensure that events are notified in the order in which they occur in return for the listener committing to an upper bound on the number of events that are pending notification.
StateChangeListener	Created by IntelliJ IDEA.

Class Summary

AvailableVerbsChangeEvent<S extends ConferencingObject<S>>	An event indicating that the available verbs for a specific ConferencingObject have changed.
ChildEvent<P,C>	A parent-child lifecycle event.
DTMFEvent	A DTMF event.
PropertiesChangeEvent	An extended form of PropertyChangeEvent that allows the receiver to obtain more information when multiple properties change in the same event.
StateChangeEvent	A state change event.

Package com.avaya.conferencing.api.acp.control.events Description

Avaya Conferencing Provider Interface Events.

Conferencing event handling faces a number of challenges:

• The volume of events generated. Consider a ConferencingProvider that can support 4,000 simultaneous calls. The average conference size is somewhere between 5 and 10 participants, therefore there can be between 800 and 400 conferences. Most conferences start on the hour, with participants connecting within a 5 minute interval, which gives a maximum call rate of approximately 15 calls per second. Establishing a call and placing that call into a conference, typically generates the most events, for example:
  • The Connection will trigger a child added event for the incoming connection.
  • If the Connection has at least one EndPointQueue with ConferencingObjectQueue.getPurposes() containing ConferencingObjectQueue.Purposes.CONNECTIONS_PENDING, that at least one of these queues will trigger a child added.
  • As the EndPoint identifies which Conference it wishes to join, it may generate multiple PropertyChangeEvents, and it may trigger opening of the Conference with its corresponding chain of events (e.g. Connection will raising a child added event for the new Conference)
  • If the EndPoint supports DTMF collection, any DTMF digits collected will raise DTMFEvents on DTMFListeners registered against the EndPoint and any of it's containers.
  • The EndPoint being placed into conference will generate a child added event on the Conference and a child removed event on any EndPointQueue with ConferencingObjectQueue.getPurposes() containing ConferencingObjectQueue.Purposes.CONNECTIONS_PENDING that raised a child added event when the EndPoint initially connected.
  • etc.
  In fact, depending on the call entry flows and the conferencing features used, it would not be unreasonable to expect upwards of 50 events to be generated per call connected. A call rate of 15 calls per second, could therefore generate upwards of 750 events per second. Allowing for the general rule of thumb that a system should be scaled to approx 2/3 of capacity, that means that each event must be processed within 1ms. A larger capacity ConferencingProvider can have event tighter processing requirements.
• Connection pooling. The ACP is designed to allow multiple clients to share a single Connection to the ConferencingProvider. Thus, for example in a JavaEE environment, there may be multiple applications using the same Connection. Each of these applications may register event listeners against ConferencingObjects. While a poorly performing event handler in one application is ultimately the responsibility of the developers of that application, the ACP should attempt in as far as possible, to isolate the effects of the poorly performing event handler from the other applications running in the same container.

For these reasons, the ACP by default uses a parallel model of event listener execution. A thread pool is used to execute events. Events are submitted to the thread pool in the order in which they occur, and event listeners are assumed to be thread safe and support parallel execution. Thus, even if processing of a previous event has not completed, the listener may be called in a separate thread to notify of a subsequent event.

It should be noted that the JVM specifications for threading do not guarantee an order in which threads will be resumed. Thus if, for example a child added event is raised and followed shortly thereafter by a child removed event (this could happen when making a call to an invalid destination), the events will be assigned to threads and scheduled for execution in the order in which they were raised, however, scheduling does not imply starting execution, and both events may be awaiting execution in the thread pool at the same time. As the JVM does not guarantee the order in which threads will be resumed, it may be that the child removed event will start execution prior to the child added event starting.

If the order of events is critical to an application, it can request that the ACP deliver events in sequence by having the event listener implement SourceSequentialEventListener. which will ensure that events will be notified to the listener instance in the order in which they occurred. ACP implementations are still free to make parallel invocations of the listener instance, however, for any one source of events, at most one event can be processed at a time. A side effect of implementing SourceSequentialEventListener is that the listener must commit to an upper bound of events that are pending notification in order to allow ACP implementations to isolate the effects of a poorly performing SourceSequentialEventListener from any other event listeners.

Since:

5.1.0.0.29