Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: manas mohanty on May 29, 2008, 01:31:12 AM
-
I see the following in the T server 7.2 logs -
UCID Changed
Common UCID Changed
I know what UCID means and how its used by T -server . Would like to know what these messages would mean and under what scenario we can see UCID changing messages ?
We have our T-server connect to Avaya Definity ECS (G3) v4 switch .
-
Is this a multisite or a single site?
-
The call has later gone across to other site through ERP. But when i see this message in logs , whole call flow till that point is of a single site. Let me give you some back ground on this. i see this call coming to a Xmobile station (Stations that are used for Extension to Cellular (EC500).These are configured to route calls to a persons cell phone when you call their desk station .) and gets released immediately. I find some very odd information after that. There is about 4 hours unaccounted where we don't find the connid in T-server logs and when the Connid reappears after 4 hours ,it does so with same ANI but a different calling and called party number .This is when i see the UCID change message. Then the call apparently gets to the IVR menu where it queues for 9 hours!!We see 2 GCDR record for the call.
-
do you have the same call-id on both the calls, the call before 4hrs and after 4 hrs?
If so, it could be the same Call-id being assigned to both the calls by PBX... we found something like that here previously...where a call was not cleared by one tserver ( can't remember which one it was, xferring or xferred one) and it retained the call info and when a call came to that tserver with same call-id, it attached all the prev call info to this current call- could that be happening? UCID would be unique for both calls though...
-
Checked the call-id. It's same before and after the unaccounted 4 hours. UCID is different though.
-
well, I think the 2nd call is a different call.
can you check if the previous call travelled through an unmonitored DN of a TServer, and the 2nd call might have come to the same Tserver....
This would cause the Tserver not to release the previous call due to lack of some events not received to it and retaining the info and appending all the old info to the new call.
-
yeah ,it seems unmonitored/disabled VDNs are involved in the call. By the way would you know why in some cases PBX would assign same call-id to two different calls? Other question that i need to resolve is how come the call waited on the menu VDN for 9 hours which does not seem practical /feasible. After 9 hour wait on IVR menu VDN ,we see the call landing on incoming VDN and getting diverted to agent .
-
If UCID is different and callid is the same than I think it's different call. Most PABX does reuse callid which is quite limited in numbers. For example, call id length on ASAI is 16 bits, which means there can be only 65536 unique callids. It is only matter of time this has to be reused.
-
yes, call-ids are reused - more like round robin- :)
Anyways, to avoid the same call-id to be used, either avoid sending the call to those unmonitored DN or prevent the client of the TServer register the DNs which it cannot recognise.
this is a tricky situation and hard to troubleshoot sometimes... ::)