Quote:
The missing digits are a real problem. I solved missing first digits by making the play before the menu "uninterruptible". It seemed the interrupting digit wasn't read.
Not sure I quite understand what you did here... Did you make all the scripts played prior to the actual "Menu" step or "Get TT String" step in TeleFlow uninterruptible? Just because the steps won't interrupt doesn't mean the touch tones detected (if and when they are) don't accumulate in the touch tone buffer (they do). Uninterruptible scripts often confuse and/or irritate callers, and they will still mash keys while listening to them. That isn't necessarily related to the problem, but I do wonder if this is fixing things, or making them worse. As a rule, I would only ever use uninterruptible scripts to make sure a particular script plays in its entirety. If you want to make sure that touch tones entered in a section don't end up collected by a Menu or Get TT String step, you can use a Clear TT to clear the touch tone buffer. (we sometimes do this after a series of scripts play where we haven't offered any menu options to the caller, just before playing the menu options and collecting the response)
Quote:
Then I raised the rxgain on the dialogic 120jct to +1. Problems went down but I'm getting digits counted twice.
We tend not to fiddle with the settings on the card, at least not these types of settings. As you noticed, you chased off one problem and found another. Before this issue is resolved, you will probably want to go back to the default for that setting. Something else is (probably) at work here. That setting will ultimately need to go back to normal to figure out what that is and solve it (especially since it appears to have created a new problem, which needs to be solved as well).
The attachments are indicative of some difficulties callers are having, but they don't identify a technical issue (the issue in the log clip, for example, could easily be user error). A large number of people complaining that they can't seem to use the system to enter keys very well will have to be the proof of a technical issue in this case.
Having said that, a couple points about the first attachment, TT interrupted.doc:
The first chunk at 11:22:32 appears to be fine. It is playing back a 10-digit number. Is there something wrong there?
The second chunk would appear to show that the caller is entering too big a number. The previous Get TT String allows 11 digits, and this caller entered an 11-digit phone number (clearly a mistake). If they entered 12+, you would further interrupts of the script. This isn't (necessarily) indicative of a technical problem, but does show a person who is having trouble.
-- This one makes me think, again, it might pay to check for a leading 1, and if it isn't present, and the string is 11 digits long, run a retry routine (Eg. "I'm sorry, the number you entered is invalid....") instead of playing back a phone number that you know isn't valid. This won't fix any touch tone detection issues, but may make a caller struggling to enter the sequence a little less frustrated.
All that said, the first thoughts coming to mind are:
1) Update to Dialogic SR 6.0. I wouldn't have expected this to be necessary, but it is always a better bet to be up-to-date.
2) What is the line quality on the lines the calls come in on? Are the prompts clear, and are the gaps/pauses with no audio quiet and clear? There isn't any buzzing or anything is there?
3) How loud are the audio prompts? Could you reduce the volume of the lot of them without it being a problem for your callers(I.e. A reduction in volume wouldn't make them immediately hard to hear, would it?)? If so, I would suggest trying that, as loud audio could have an impact.