Thanks Gergely   We will look into the Proxy, the caller needs to be informed if the information they entered was correct or not, so we must have a return from the DB or the API. So from a load perspective on the UCCX, the HTTP to Proxy would be less of a load than calling straight to DB? I have never done a comparison. I know that the DB calls are much faster than the HTTP API calls that I am doing.   By the way, I do appreciate all of your posts on this forum.   Thanks Danny ... View more

Thanks Gergely, for responding. We have over written our logs, so I can't provide the logs for the last time that we had this occur (09/29/2014). TAC transferred the logs via the WebEx and they are not attached to the case. I did forget to mention that every time that we have this happen, we are getting a Code Yellow on the CUCM that is the main call processor for the UCCX. TAC has indicated that the CUCM is unable to write all of the logs, cdrs, etc under the high call volume. I am following up behind another Cisco partner and I do not believe that the UCS were sized correctly for my customers call volume. They are running Cisco UCS C220-M3 LFF with the 7.2 SATA drives. We have virtually disabled all logging on the CUCM as to lower the impact of all of the holds, transfers, etc. The previous partner had written a lot of custom JAVA for doing the database and backend API integration. This took a very long tome to execute on each of the calls, 20 -30 seconds or longer per call. I have rewritten scripts to do all of the integrations, via subflows and reduced this time to 5 - 10 seconds.   In the mean time, I have removed all instances of placing calls on hold, by playing prompts instead of placing them on hold, where I can. I have also combined scripts as to reduce transferring from script to another script. So I have lessened holds and transfer by about 60%. We have been unable to tell if this working or not, as we have to wait for the next large power outage. The one place that I am unable to remove placing the caller on hold is when, we do the database dips or call the backend API(HTTP), any suggestions? Any help, pointers, information would be greatly appreciated as the customer is getting very frustrated. I was under the impression that when the CTI port placed the caller on hold, that it was still reserved for that contact to return from being on hold or transferring? Thanks Danny       ... View more

Thanks Gergely, I am aware of JAVA, just cumbersome as you stated. I will look into the Cache Document step. I have not used it in the past will have to learn the nuance of this. Thanks Danny ... View more

Thanks Chakshu for pursing this. I just found my issue. I am running UCCX in an HA cluster. I made the change to the System > System Parameters on the Primary Node, but it wasn't the master. The System > System Parameters doesn't replicate the change to the secondary node. So after making the change on the secondary node it is working now. ... View more

Chakshu Under prompt management en_US, i have created a gen folder. Under the gen folder I created a number folder and a phone folder. I uploaded 0.wav - 9.wav. I can play these prompts without any issues with a play prompt step. I am using the step Generate Prompt for playing the calling number back to the caller. I want this to be in our voice not the system prompts. Thanks Danny ... View more

Thanks Chaksu, I have already been through that post as well. It did not provide a solution. ... View more

Thanks for the input leosalcie. I created the folders under the user language en_US/gen/number and en_US/gen/telephone. When using the generate prompt step, you can't tell the system where to look for the prompts that I am aware of. It uses the system language prompts for the type of prompt that you are trying to generate. That is why we have the Use user prompts override setting. Thanks ... View more

I am also having this issue with a customer. Did you ever resolve the issue? ... View more