I have asterisk-1.6.2.22 installed on my CentOS system.
I have setup the inbound call IVRs on my server. Its working fine. In my setup the caller is giving input. The numeric input works well. But I want the caller to input the alpha-numeric values from the phone. That alpha-numeric values I want to insert into database.
for example : the caller have to input - ‘123AL45D’
DTMFtoText was one third party applicaiton. But right now it is not available.
Is there any application available ? or any help ?
DTMF can only generate 16 values: 10 digits, *, #, and four others. The remaining four are normally labelled A, B, C and D, but I’d hardly call that alpha-numeric.
I want to get input from the caller. If the user input is numeric then there is no issue.
But I want the caller to enter from their phone something like :
How can I get this values ? I can easily get the 10 digits. But have the issues with alphabets.
If you are limited to using DTMF, rather than the internet or a general purpose modem, and cannot use tracking numbers that are appropriate for DTMF input, either issue smart phones and program them to convert the codes to the DTMF alphabet, or use voice recognition. Trying to implement something like the the pre-tablet SMS interfaces without fast visual feedback is going to be too painful to use.
As last resorts, create a standalone device that takes the alphanumeric coding and creates a numeric string, but expect a large number of data entry errors, or use the SMS type coding, with either * or a pause between letters on the same key, and give spoken confirmation after each character.
Your employees will greatly appreciate a change to modern communication methods, or the use of DTMF friendly codes.
I echo David’s statements on alternative input methods, however I know that this is sometimes not possible because of reasons beyond your control.
What I have done is the past is convert the digit string into an ‘array’ of all possible alpha numeric cobinations and query the database with a ‘select… in ( array as a list )’. If a single row is returned, ok. If multiple rows are returned present the caller with a list of possible values and let them choose
This may or may not work for you depending on how structered your tracking number is. If your ‘number’ is always in the format of X999XX9 the combinations are managable. If the format is such that any possition could be alpha, the number of possible combinations gets quite large and impractical for this approach.
However, if you already know the employee number, you may be able to limit the search to items which are still open and that are assigned to that employee and then present a smaller list.
I’d rejected the directory approach, but handn’t considered that one could use context to limit the vocabulary.
However one would need to take into consideration that the check digits in the code would no longer be reliable, so one would not have to just consider matches which reduced to the same digit string, but ones which reduced to single digit errors and transpositions of it (check digits would also protect against more complex errors).
I too would suggest that the random number/letter approach be dropped if at all possible. If you’re using unique values for your tracking numbers, you’re going to use over 2100 Unique codes just to have a single match for the string you presented earlier! It would serve you better, and be faster to input and navigate, to just move to 8 or even 10 digit tracking codes.