tscp.call {destructed} entry in TServer 7.5 logs, is the real end of the call?

[Gef Buneri]

Hi all again, as in object.


Gef.

**** Seems like the call dies, telephonically speaking, during the first event, but logically it remains on the system, being destructed after some sort of "timeout", during the second event.

**** I mean, in the TServer logs I have 2 release events (x5520 is the station that received the call):

1st:

@18:38:17.1571 [asai] (processEvReportDisconnect)
@18:38:17.1571 [gctmi] TMsg [EventReleased()] distributing to model
@18:38:17.1572 [gctmi] Call [009c02c0df27d9b6/28c4,sES,t1M,l1] distributing EventReleased
@18:38:17.1572 [gctmi] Call [009c02c0df27d9b6/28c4,sES,t1M,l1] processReleased
@18:38:17.1572 [gctmi] Call [009c02c0df27d9b6/28c4,sES,t1M,l1] EvRelease ignored for non-exist party.
@18:38:17.1578 [<<] 08 00 00 2A 08 02 83 C0 62 96 1C 22 91 A1 1F 02 01 02 02 01 95 40 17 08 02 81 A9 0C 06 80 23 23 23 23 23 10 02 28 C4 96 44 01 81 47 01 84
TP_AsaiData
FACILITY  CRV:83c0
Facility: INVOKE
InvokeId: 2
Operation: EventReport
Cause: C_TEMP_FAILURE
ConnectedNum[1]: (unknown),'#####'
CallID[1]: 10436
PartyId[1]: 1
Event[1]: Disconnect
@18:38:17.1578 [asai] (processEvReportDisconnect)
@18:38:17.1578 [gctmi] TMsg [EventReleased()] distributing to model
@18:38:17.1578 [gctmi] Call [009c02c0df27d9b6/28c4,sES,t1M,l1] distributing EventReleased
@18:38:17.1578 [gctmi] Call [009c02c0df27d9b6/28c4,sES,t1M,l1] processReleased
@18:38:17.1578 [gctmi] Call [009c02c0df27d9b6/28c4,sES,t1M,l1] EvRelease ignored for non-exist party.

and a second, 12 minutes later:

18:52:23.671 Trc 04542 EventReserved_2 sent to [15] (00000005 ccp_statserver x.x.x.x:xxxx)
18:52:23.671 Trc 04542 EventReserved_2 sent to [14] (00000004 StatServer75URS x.x.x.x:xxxx)
18:52:23.704 Trc 04541 RequestReleaseCall received from [19] (0000032b Gplus adapter x.x.x.x:xxxx)
message RequestReleaseCall
AttributeThisDN 'x5520'
AttributeConnID 009c02c0df27d9b6
AttributeReferenceID 3994
18:52:23.704 Int 04543 Interaction message "RequestReleaseCall" received from 19 ("Gplus adapter")
@18:52:23.7042 [gctmi] Distributing request RequestReleaseCall
@18:52:23.7042 [asai] Party [009c02c0df27d9b6:x5520,sc,tDN,rDST,lINT] (reqReleaseCall)
TP_AsaiData
FACILITY  CRV:3c0
Facility: INVOKE
InvokeId: 3
Operation: TP_SelectiveDrop
CallID: 10436
@18:52:23.7043 [>>] 08 00 00 17 08 02 03 C0 62 96 1C 0F 91 A1 0C 02 01 03 02 01 88 40 04 10 02 28 C4
@18:52:23.7157 [<<] 08 00 00 0E 08 02 83 C0 62 96 1C 06 91 A2 03 02 01 03
TP_AsaiData
FACILITY  CRV:83c0
Facility: RETURN_RESULT
InvokeId: 3
@18:52:23.7157 [asai] (processRtrnRsltReleaseCall)
@18:52:23.7157 [gctmi] request RequestReleaseCall deactivated in reqMgr
@18:52:23.7157 [gctmi] TMsg [EventReleased()] distributing to model
@18:52:23.7158 [gctmi] Call [009c02c0df27d9b6/28c4,sES,t1M,l1] distributing EventReleased
@18:52:23.7158 [gctmi] Call [009c02c0df27d9b6/28c4,sES,t1M,l1] processReleased
@18:52:23.7158 [gctmi] TMsg [EventReleased(x5520)] (re)distributing to model in 500mS
@18:52:23.7170 [<<] 08 00 00 2A 08 02 81 BC 62 96 1C 22 91 A1 1F 02 01 02 02 01 95 40 17 08 02 81 90 0C 06 FF 34 35 35 32 30 10 02 28 C4 96 44 01 82 47 01 84
TP_AsaiData
FACILITY  CRV:81bc
Facility: INVOKE
InvokeId: 2
Operation: EventReport
Cause: C_NORMAL
ConnectedNum[1]: (local),'x5520'
CallID[1]: 10436
PartyId[1]: 2
Event[1]: Disconnect
@18:52:23.7171 [asai] (processEvReportDisconnect)
@18:52:23.7171 [gctmi] TMsg [EventReleased(x5520)] distributing to model
@18:52:23.7171 [gctmi] Call [009c02c0df27d9b6/28c4,sES,t1M,l1] distributing EventReleased
@18:52:23.7171 [gctmi] Call [009c02c0df27d9b6/28c4,sES,t1M,l1] processReleased
@18:52:23.7171 [gctmi] TMsg [EventReleased(x5520)] (re)distributing to model in 500mS

[victor]

EventReleased is the true disconnect.

They keep the call in memory after that in case of a fail-over or in case the call was routed to a not-monitored DN.  I think destructed is when the release it after the timeout. Anyone to confirm?

[Gef Buneri]

Thanks Victor, I did studied some cases, and it seems as supposed: 1st processReleased with t1M reason in the event is the "true" disconnection, telephonically speaking, then the call destructed indicates the end of the logical life of the call (timeout, etc.). In some case you have an early processReleased with a t0M in the string, but it seems more the release of the "system virtual party" to pass the interaction to the final party.


Gef.