Author Message
AshishPaliwal
Joined: Dec 13, 2013
Messages: 4
Offline
Hi Team,

Our IVR team has developed one application, in that we have issue when call is transferred back from IVR to Agent our TSAPI licenses on AES drop drsatically even for single call.

I have captured AES logs below, can someone help me understand that:

03/19/2014 02:15:06.827:TSAPI:LinkThread01: cap,prim,sao_id C_VQ_CONF,C_NEG_ACK,26
03/19/2014 02:15:06.827:TSAPI:LinkThread01: cause_value CS0/28
03/19/2014 02:15:06.827:TSAPI:LinkThread01: vqc_type 6
03/19/2014 02:15:06.827:TSAPI:LinkThread01: Sent CSTA Msg (CSTACONFIRMATION)(5) (UNIVERSAL_FAILURE_CONF)(53)
03/19/2014 02:15:06.827:TSAPI:LinkThread01: msgoff(24)msglen(4)privoff(0)privlen(0)
03/19/2014 02:15:06.827:TSAPI:LinkThread01: invokeID(26)monXref(2989)sessionID(5)clsOfServ(0)
03/19/2014 02:15:06.827:TSAPI:LinkThread01: error(INVALID_CSTA_DEVICE_IDENTIFIER)(12)
03/19/2014 02:15:06.830:TSAPI:CMRYDH01: Received CSTA Msg (CSTAREQUEST)(3) (SNAPSHOT_DEVICE)(122)
03/19/2014 02:15:06.830:TSAPI:CMRYDH01: msgoff(24)msglen(64)privoff(24)privlen(0)
03/19/2014 02:15:06.830:TSAPI:CMRYDH01: invokeID(27)monXref(0)sessionID(5)clsOfServ(0)
03/19/2014 02:15:06.830:TSAPI:CMRYDH01: snapshotObject(80401)
03/19/2014 02:15:06.831:TSAPI:CMRYDH01: Sent ASAI Message VQCallStat
03/19/2014 02:15:06.831:TSAPI:CMRYDH01: cap,prim,sao_id C_VQ_REQ,C_REQUEST,28
03/19/2014 02:15:06.831:TSAPI:CMRYDH01: extension 80401
03/19/2014 02:15:06.831:TSAPI:CMRYDH01: vq_item 8
03/19/2014 02:15:06.879:TSAPI:LinkThread01: Received ASAI Message VQCCallStat
03/19/2014 02:15:06.879:TSAPI:LinkThread01: cap,prim,sao_id C_VQ_CONF,C_POS_ACK,28
03/19/2014 02:15:06.879:TSAPI:LinkThread01: vqc_type 8
03/19/2014 02:15:06.879:TSAPI:LinkThread01: num_call 0
03/19/2014 02:15:06.879:TSAPI:LinkThread01: Sent CSTA Msg (CSTACONFIRMATION)(5) (SNAPSHOT_DEVICE_CONF)(123)
03/19/2014 02:15:06.879:TSAPI:LinkThread01: msgoff(24)msglen(8)privoff(32)privlen(41)
03/19/2014 02:15:06.879:TSAPI:LinkThread01: invokeID(27)monXref(2989)sessionID(5)clsOfServ(0)
03/19/2014 02:15:06.879:TSAPI:LinkThread01: snapshotDatacount(0)
03/19/2014 02:15:06.879:TSAPI:LinkThread01: eventType(ATT_SNAPSHOT_DEVICE_CONF)(72)
03/19/2014 02:15:06.879:TSAPI:LinkThread01: count(0)
03/19/2014 02:15:06.882:TSAPI:CMRYDH01: Received CSTA Msg (CSTAREQUEST)(3) (QUERY_DEVICE_INFO)(37)
03/19/2014 02:15:06.882:TSAPI:CMRYDH01: msgoff(24)msglen(64)privoff(24)privlen(0)
03/19/2014 02:15:06.882:TSAPI:CMRYDH01: invokeID(28)monXref(0)sessionID(5)clsOfServ(0)
03/19/2014 02:15:06.882:TSAPI:CMRYDH01: device(80402)
MartinFlynn
Joined: Nov 30, 2009
Messages: 1922
Offline
When the TSAPI service on the AE Services is monitoring a station/call it will query the Communication Manager about any numbers of which it becomes aware. So, for example, if a monitored station calls another number, the TSAPI service will perform a SNAPSHOT_DEVICE_CONF on the new number to find out more about it.

So, in your example, the first number queried (query not shown) returns INVALID_CSTA_DEVICE_IDENTIFIER so TSAPI now knows the number is not on this switch. The second request, for 80401 is a valid number.

I would not expect any of these traces to lead to an increase in the number of TSAPI licenses in use.

Martin

Go to:   
Mobile view