What little I know about this call flow is that experience portal collects information from the call, and then populates the Oceana database with information about the call. It then sends the call off towards Oceana to be dispatched to an agent. Most likely EP is using UCID in the attributes it puts into the DB and attaching UCID information to the call so things are bound back together when the moment comes to dispatch the call to an agent. It may be using UUI data and creating its own UCID equivalent. Unfortunately, I don't know.
In a working Oceana environment, you could examine the SIP messaging between EP and Communication Manager and try to understand what was happening (or examine the information getting populated in to the DB). You may be able to find logs for the DB and see what is being queried with (UUI/UCID) and what attributes are being queried for... but you would still need a way to populate this information in both the call and the DB before you stood a chance of getting past the gate you are at. Getting past this first gate doesn't mean that you will succeed either. The call flow may have more dependencies than I am aware of on the initial handling by EP.
Since you are really trying to subvert the way Oceana is designed to work, beyond that insight, I can not help you further.
|