We got a problem. Some customers who called IVR get a prompt about system error. At first they hear welcome prompt and then error prompt. It seams like a call can't reach a queue. The problem is float. There is no any system. But I noticed some error messages in application log in the time wich problem occured. The messages like follow:
FCRasServer2019 SQL Query failed with SQL error could not prepare the SQL statement for query INSERT INTO FCRasStateLogToday (dcServerID, dnGlobalID, dnStateStartTime, dnStateStopTime, dnStateWDay, dcAgentID, dcAgentExtension, dnAgentState, dnAgentReasonCode) VALUES (0x5ce02052415300000d2c0067, 1342069359, 1342080607, 1342080624, 4, N'kinchina', N'kinchina', 21, 0).
FCRasServer2101 Unable to retrieve data, query is SELECT SL.dcServerID, SL.dnGlobalID, SL.dnStateStartTime, SL.dnStateStopTime, SL.dcAgentID, SL.dcAgentExtension, SL.dnAgentState, SL.dnAgentReasonCode, CL.dcCallWrapupData FROM FCRasStateLogToday AS SL LEFT OUTER JOIN FCRasCallLogWeek AS CL ON SL.dcServerID = CL.dcServerID and SL.dnGlobalID = CL.dnGlobalID WHERE SL.dnStateStopTime >= DATEDIFF(second, DATEADD(second, DATEDIFF(second, GETUTCDATE(), GETDATE()), '1/1/1970'), DATEADD(Day, DATEDIFF(Day, 0, GETDATE()), 0)) and SL.dcAgentID = N'tsedenov'.
What does it mean and could these DB errors be a cause of the problem?
Whenever I have trouble with a script, the first thing I do is turn on tracing for ENG debugging. This will put each script step in the MIVR (Engine) log files, and makes tracing down failing steps a lot easier.
The amount of logs you presented, along with the information, is not enough to properly troubleshoot your issue.
I suggest you run a reactive debug on the failing script, and step over each step, one at a time, and inspect what's happening in real time.
If an exception is thrown, but you do not have enough details on why, then go to the MIVR (Engine) logs.
As a quick work around, if you see which step is failing the script, and you can safely bypass it, for the greater good of the caller, I would just put a label after it, and a goto above it, and "jump" over it. Then, make a copy of your script, create a new test app, with a new test trigger, and debug it offline while your callers still get to where they need to be.
Good luck and happy debugging!
Please use the star ratings to help drive great content to the top of searches.
Please use the star ratings to help drive great content to the top of searches.
In addition to what Anthony said, I will point out that it sounds like you've already isolated this to some database steps. I have seen this problem commonly if there is a database connection problem. You didn't say, but I'm assuming that this script was working and for some reason started having issues.
If you open the script editor on the server, and open up the database steps, you should be able to verify that the database connection is in place. If you push apply, and it blows up, you may need to refresh the database connection. Open each of the database steps, and make sure they are pointed at the correct database connection (hitting apply isn't a bad idea).
Once you've done this, validate the script, and save it back to the repository. Refresh the script, and then do a reactive debug so you can walk through the script one step at a time and see where it blows up and why (if it still has issues).
The script is in attachment. And it is quite simple and hasn't any DB-steps. I think the problem is not in the script logic because all the calls move the same way and only part of them get this error. I turned on ENG debugging as you suggested me but it isn't much informative for me. May be you could see anything (log in attach.). The problem occured today between 10.30 and 10.40 and then was repeating several times.
I tried to change a Call Control Group on triggers of the applications and noteced that the application wich use this script was using numbers of CTI port of the previous Call Control Group. In the previous group there are no enough CTI port to handle big amount of all calls.
Could you tell me may be a lack of CTI porrts could be a cause of the problem? Please correct me if I'm wrong - I suppose that IVR pronounced WelcomePrompt and then try to connect an agent but connection requires a free CTI-port which is absent at that moment.
You definately have some sort of resource issue. From your logs (Scroll down to bolded text):
Unable to hold connection; nested exception is:
com.cisco.jtapi.ResourceUnavailableExceptionImpl: Unable to hold call.
I also see:
Cannot allocate an available resource b/c none is present in SBRF_Ter_CSQ1
You might ought to run this one by TAC. It could potentially be a licensing issue, or it could be an issue with partitions and call search spaces (if it's attempting to transfer to an agent and can't, but normally that wouldn't produce this error).
However, it might be something slightly different. You've got a step in the queued branch to get the expected wait time. If no resources are logged in to that Queue, then the expected wait time could be null, undefined, etc. You may be trying to test values against something that is coming up null. That actually may be where your issue is coming from. You'd need to do some testing with it to see if this is true, but running it in reactive debug so you can see which step fails, what the variable values are, etc. would be how I would chase this.
Unfortunatelly this equipment is not already supported.
I tried to use script without GetReportStatistic step and prompts with the same result - part of calls rieach an error prompt. I checked CSS and partitions - it's not a cause of the problem. I tried run it in reactive debug but it just opened the script, marked the Start step and that's all. I couldn't see all the steps. May be I do something wrong...
I noticed that when load of calls is not big everything works fine. And the problem occures usually at the peak of traffic. I checked that the application use right cti-ports and will test it on monday morning.
Ok....sounds like you need help with reactive debug.
When you start reactive debugging, the debugger starts when you fire the script (by calling it). It comes up on step one, and WILL STAY THERE until you do something.
You can either hit the "PLAY" button on the tool bar, and it will take off and run fairly normally (if a bit slower). You can also single step through using the appropriate button on the tool bar for a single step.
You can also set a break point (once the script is up), and hit the run button to allow the scropt to run normally to that point, and then stop (allowing you to shift into one step at a time mode).
When the script is stopped on a step, you can scroll through the variable list and see what value is in each variable at the time. If a step causes an error, and you're single stepping, you'll normally know which step you were on, see the error in either a pop up dialog or in the lower right hand pane. sometimes I have to run a few times through after getting the error, so I can look at what the variables are doing going into that particular step.
If it's only occurring at peak traffic, you may have something else going on. Again, take the logs to TAC and let them help you with specifics.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...