For Direct Agent Call initiating via EP's application, JTAPI client no convey the FailEvent.FailedConnection<Null> to the AESConnector

Doc ID		SOLN313424
Version:		1.0
Status:		Published
Published date:		03 Aug 2017

Author:

Dongbo Zhao

Details

CM : 7.0.1.2.0.441.23523
AES: 7.0.1.0.4.15-0
AEP(EPMS/VPMS):7.1.0.1.0006
OD:7.1
Jtapi Client version:6.3.3.27

Normal message interaction should be like below:
1: DD application=> AESConnetor=>JTAPI client => hold Event => AES => CM
2: DD application=> AESConnetor=>JTAPI client => Dial Event =>AES => CM
3: CM => ASAI busylist => AES => TSAPI Failed EventFailedConnection<No-Null>=> Jtapi client => AESConnetor
4: AESConnetor=> TSAPI CSTAClearConnection message => AES => CM
5: DD application=> AESConnetor=>JTAPI client => RetrieveCall(un-hold)=>AES => CM

Abnormal message interaction like below:
1: DD application=> AESConnetor=>JTAPI client => hold Event => AES => CM (for holding a incoming original call )
2: DD application=> AESConnetor=>JTAPI client => Dial Event =>AES => CM (starting a Direct Agent Call )
3: CM => ASAI busylist => AES => TSAPI Failed Event.FailedConnection<Null>=> Jtapi client => AESConnetor (because Agent is busy state)
because when JTAPI Client find the FailedConnection is null , then JTAPI client stops to convey this Failled event to AESConnetor .
so AESConnetor does not start sending the CSTAClearConnection to AES=>CM to hungup the second call leg from CM,
4: DD application=> AESConnetor=>JTAPI client => RetrieveCall(un-hold)=>AES => CM
CM would deny the CTI RetrieveCall(un-hold) request in the transferring party is talking on calls.

Problem Clarification

an MR enhancement related to user busylist ASAI event. this was delivered starting in CM 6.3.6
defsw132171 - AES/CM FP4: AES CTI event ASAI/TSAPI user busy 162834-8014
As per the MR, The original ASAI busy event only included the call ID, the called number, and a cause value. Note that the called number often was not the actual busy
number. The new busy event will also now include the calling number and the actual busy number (sent in the connected number IE). The evnt_busy structure
defined in isg_calls.h already had the members to contain this information, so it did not need to change. However, two of the members were not currently
populated - the busy_uid and the orig_uid. The busy_uid will now contain the UID of the actual busy endpoint, and the orig_uid will contain the UID
of the calling party.. It has been enhanced to provide the calling number and the connected number (which will be the actual busy endpoint).
CONNECTED NUMBER of busylist event for call to agent could be Null, it is working as design, which would result in AES send Failed event with FailedConnection<Null> to JTAPI client.

JTAPI client should has ablity to hanlde this event and convey this FailEvent.FailedConnection<Null> to application like AESconnector. but now the problem is JTAPI client drops the event.

Cause

it is caused via the Jtapi client bug.

Solution

AES R&D team is going to fix this issue in future release JTAPI client with JIRAumber AES-16575.

Attachment Description

Additional Relevant Phrases

Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy