I have a simple application to register phone numbers. Occasionally, "get TT string" doesn't pick up one of the input numbers. Of course, it reads back an incorrect number. In 3 caller tries it can miss 3 different digits - but so far, always a single digit in a 10 digit string. After the caller gets kicked out, there is no record in the list of numbers generated, although it shows in the very long and extensive linelog.

I started with5.1.1 build 0. To try to fix the problem I added FP1. Still no luck but it shows build 149.

Any suggestions or a work around?

Can you provide a line log in which this problem occurs, from "Wait for Call" through to "Hang Up"?

It would help if you replicate the issue yourself, and provide a single call log with the problem. You can then explain what number you are trying to enter. (you can make sure it is a test/fake number this way, as well, if there is anything sensitive about the data you are working with)

Thanks!

It seems to happen at random, and there is no consistency as to which digit is missed. I allow 3 tries and all three can fail. Example attached.
Thanks

There doesn't appear to be an attachment. Can you try that again?

hope this works.

There's nothing obviously wrong in the logs that I can see.

How did you come to the conclusion that the system is actually missing digits? I do see in the log where entries had to be made more than once, but human error in such a system is not uncommon, so how did you determine this is actually a problem with the system, and not just an occasional mistake made by the user entering the number? (in ex 1.doc, I see that the get tt string exited, and immediately after that, the caller pressed # before they heard the next prompt. This suggests some confusion on the caller's part, which leads me back to thinking it could just be a user error)

A couple that might help make the issue less bothersome:

1) Is the pound termination required? You could make that Get TT String only accept 10-digit numbers, and prompt the caller as such. "Please enter your 10-digit phone number now". This reduces the keys they must press, and makes testing the phone number after the step easier.

2) The system plays the number back to the caller, even if the number is a length that is obviously not valid. You could test the number for length, and only play it for confirmation if it is 10 digits in length. Otherwise, prompt the caller to enter it again.

Glad to hear errors are common as I can see callers indicating the readback is correct when first digit of area code is missing. On the other hand, I have had calls to my office with the caller swearing he's tried correctly 3 times. I also have various streams before and after checking length. I accept 10 or 11- if 11, I remove last digit (#). I write before and after the length check to give a clue to the correct number, but this involves manual checking.

I was worried that Dialogic was missing the digits but I guess you don't think so. .

Sounds like I'll have to live with it & save the logs for my buddies at the crtc.

P S Since 1993 I've had a PIKA A board with a lot of errors but had heard this board was notorious for missing digits - so you can see my concern.

Maybe not common, but common enough at any rate (and the longer the number, the more likely the user error is). We haven't encountered randomly missed digits with Dialogic, so no, there isn't any reason to suspect the hardware is at fault on this one.

I'm sure the checks for length and such are all fine, was just noting some things I wondered about. (although, since you only accept a 10/11 digit number, it might still pay to not play 9 digit numbers back to the caller for their confirmation when you know the number can't be right)

many, many thanks

Hello Again.
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.

Then I raised the rxgain on the dialogic 120jct to +1. Problems went down but I'm getting digits counted twice.

I'm attaching two files. One is taken right after digit entry (before readback). It shows people are working pretty hard to input correctly - and often failing.
The other is a portion from the log showing an "interrupted" after each digit readback for a misregistered number.

Any thoughts?

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)


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.

Thanks for your detailed reply.

I’ll start with 2 things that might be killers.
1. All the specs say to use a faster machine than I have (P2 – 400 with 198 RAM).

2. Incoming is VOIP & this always seemed like the most likely culprit. The supplier says definitely not. Certainly the voice quality is good.

3. Did I not read that Dialogic 6 is not supported in the open source version? (and I’m not keen on buying it)

The sequence in my flowchart is Clear TT, Menu Set , Play Greeting (For Caller Choice), Menu_Opt, Play (enter number) – made this non-interruptable, Get TT – I write a log here to check entry before readback, Readback, Etc

Re Interruptible:
I called in while listening on earphones to the receiving end. Every time I pressed a digit during the play step, Interruptible, (enter your number), that digit was not registered.

I also called in a few times (non-interruptible) and heard the error of missing digits at varying places within the 10 digits, myself.
It happens at 25 to 50% although many get corrected on retry.

Complaints
I’m getting plenty, including being accused of sabotaging the system so people won’t register. (People do make mistakes & I can see them in reading input at various places but this problem is genuine)

Prompt Volume
I can’t get it as loud as the default – even boosting volume to 1.

RxGain
Yes – I reset it to default (I had seen a set of installation instructions somewhere that said to raise it)

While I can't say anything definitive about whether or not the hardware you are using is having an impact on the lost touch tones issue, troubleshooting an issue on a system that is this far below minimum specifications isn't likely to yield the results you are looking for.

I would recommend against a computer of those specs even for development or testing/lab duty, let alone for production use.

At this point, I think we should hold off on further troubleshooting steps until this application is running on a system that at least meets the minimum requirements for TeleFlow and Dialogic.

Sorry - I was wrong on the specs. Minimum was 233mz. I put it on a 2.33Mhz with 500 + megs ram. Results same although file attached may make it easier to see what is happening.

(I was thinking of putting on a transfer to voice mail. Darned if I can't get it to work - but I guess that's another forum.)

I'm assuming you meant 2.33GHz, which is probably OK for a light-duty server. As for the RAM, the "right" amount isn't so much the number, as what is needed to do the job. If you're on Window 2000, 512mb might be OK (depending on the memory needs of all the services / programs your server is running), but on XP, the operating system alone pretty much needs that to itself.

The log wasn't attached, so I can't see the log that has a better example of the problem. Please attach again.

Also, do you by any chance have a regular analog line (I.e. One not coming via a VoIP provider) you can plug in temporarily just for you own testing? Or, perhaps an analog ring simulator? It would be well worthwhile to test with one of these if you can, and see if the results differ any.

out of town for a while. Will try land line on return - great idea. In the meantime, here is the file missing from last reply to show you pattern (?) of errors.

The land line is probably the next best thing to look at.

Also, previously, when I mentioned prompt volume (I.e. the volume of the audio played to the caller), I was hoping to know if you could decrease/reduce the volume without it being too quiet (I.e. Can you reduce the volume without making the system so quiet the caller's can't hear the system?). This could help.

As for the log of issues, I'm not always 100% sure what I'm looking at (because I don't know precisely what you are identifying in each case), but, I did notice a couple things that seemed odd:

1) The first "TRY 1" entry has a complete 10-digit phone number, which then gets done wrong for TRY 2, and then is noted as OK at 10:28. The oddity there is that the phone number was correct the first time, so why did the caller end up having to enter it again?

2) The first "WRONG ?" is noted as "TOO LONG". It looks like a 10-digit phone number. What was the problem with this one?

3) There are a number of "WRONG ?" that are 10-digit phone numbers. I don't know what is wrong about them... I guess I just don't know what your system is in this spreadsheet.

4) The last two entries are "WRONG ?" and noted at "TOO LONG", but they both appear to be 10-digit phone numbers?

You've been so helpful, I've hesitated to write again.

But, I think some progress is being made. I discovered that the Linksys was not set to inband and its fxs gain was -3. So the first section is FXS 0 and lated DTMF was changed to inband.

Sorry it's long, but I hopped to find patterns. The attached is what is input - it is written directly after getTT and getTT is set to max 11. I've put blank lines to separate out the errors for ease of reading. The system is better than it looks as I've removed the successes to limit file size.

The biggest problems seem to involve digits 4,1,6 with either missing in the first 3 digits, or 416 repeated as digits in position 4,5,6, or a 4 as the last digit.

I wonder if there is a programming sequence I can us to limit errors without delaying callers. I have managed to add voice mail after a number of failures, hoping to avoid people calling to curse me & to limit their frustration, but it's another batch of work to take off messages - it would be better to limit this.

It's time to try a regular analog line on this system for some testing.

Let us know the results of that.