AES: TSAPI messages doesn't contain ANI when the call is consultation tranfered from extension


Doc ID    SOLN290242
Version:    3.0
Status:    Published
Published date:    15 Jun 2020
Created Date:    29 May 2016
Author:   
Jingui Zhang
 

Details

Any AES version.

Problem Clarification

External Number call an attendant console, and then the attendant console transfer the call to another internal extension, and this extension is monitored by AES server.

The issue is when it's blind transfer, calling number can be found in TSAPI message; if it's consultation transfer, calling number cannot be found in TSAPI message.

 

 

 

Cause

Working as design.

In the A call B consultation transfer to C case, if B is not monitored by same AES that monitors C, CM will not send the calling number to AES in ASAI transferred message:

 

02/16/2016 00:34:46.527:TSAPI:LinkThread01: Received ASAI Message TranList
02/16/2016 00:34:46.527:TSAPI:LinkThread01: cap,prim,sao_id             C_EN_REP,C_REQUEST,55758
02/16/2016 00:34:46.527:TSAPI:LinkThread01: event_name                  C_TRANSFERED
02/16/2016 00:34:46.527:TSAPI:LinkThread01: callID                      348
02/16/2016 00:34:46.527:TSAPI:LinkThread01: oldCallID,newCallID         347,348
02/16/2016 00:34:46.527:TSAPI:LinkThread01: bef,aft_call_id             347,348
02/16/2016 00:34:46.527:TSAPI:LinkThread01: called_num                  8141202
02/16/2016 00:34:46.527:TSAPI:LinkThread01: calling_num                 8220000
02/16/2016 00:34:46.527:TSAPI:LinkThread01: num_parties                 2
02/16/2016 00:34:46.527:TSAPI:LinkThread01: merge_ext[0]:
02/16/2016 00:34:46.527:TSAPI:LinkThread01:  [newCallID,oldCallID,party_id]      348,348,2
02/16/2016 00:34:46.527:TSAPI:LinkThread01:  [old_pid,which_call,extension]      2,64,8141202
02/16/2016 00:34:46.527:TSAPI:LinkThread01:  [ext_type[addr_type,numb_plan]]     7,15
02/16/2016 00:34:46.527:TSAPI:LinkThread01: trk[id,gid,direct]          0,0,0x0
02/16/2016 00:34:46.527:TSAPI:LinkThread01: merge_ext[1]:
02/16/2016 00:34:46.527:TSAPI:LinkThread01:  [newCallID,oldCallID,party_id]      348,347,1
02/16/2016 00:34:46.527:TSAPI:LinkThread01:  [old_pid,which_call,extension]      1,0,(null)
02/16/2016 00:34:46.527:TSAPI:LinkThread01:  [ext_type[addr_type,numb_plan]]     0,0
02/16/2016 00:34:46.527:TSAPI:LinkThread01: trk[id,gid,direct]          1,51,0x0
02/16/2016 00:34:46.527:TSAPI:LinkThread01: called_type[addr_type,numb_plan]     7,15
02/16/2016 00:34:46.527:TSAPI:LinkThread01: calling_type[addr_type,numb_plan]    7,15
02/16/2016 00:34:46.527:TSAPI:LinkThread01: ucid:  8 byte dump of 8 bytes of data:
02/16/2016 00:34:46.527:TSAPI:LinkThread01: ucid:  hex '0001015b 56c1ef53'
02/16/2016 00:34:46.527:TSAPI:LinkThread01: ucid:  std format: '00001003471455550291'

In this case, transferred station is monitored by AES, but the transferring station is an attendant console, it cannot be monitored by AES, so the calling number will not present on TSAPI message.

Solution

work as design.

Using blind transfer instead consultation transfer at this moment.


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