I’m trying to create an IVR that uses the A, B, C, and D DTMF tones for certain menu options. When I do so, however, hitting ‘Submit’ results in a, “Please enter valid value for Digits Pressed” error.
I realise that my use case is probably fairly esoteric, but is there a way to make this functional? It’s something that I need to have working for a demonstration system that’s being set up.
This is on FreePBX 14.0.11 running under RasPBX on Raspbian Stretch. Modules, OS, etc. are updated to current.
Look at a phone key pad that has been in existence forever, A, B, C are 1 D, E, F are 2, etc. That means when you enter DAD you’re entering 212 or DEE is 222. There are no tones for alpha characters just digits. That’s why the letters are translated to digits.
Look at the history of DTMF (DualToneMultiFrequency) anticipated binary math used in computers nd has ABCD as 1633 Hz combined with the lower 4 tones, and yes asterisk is aware of them, as to whether FREEPBX can be patched PHP wise everywhere and whether it is Case dependent is another question. but pathing the regexes as necessary to include a-d and A-D withen the square brackets might suffice, you could make a feature request, but I wouldn’t put much chance on it being done for you.
OK, yeah this exists but its use isn’t standard and most carriers don’t even allow them or let them go through. As per your link “Present-day uses of the A, B, C and D keys on telephone networks are few, and exclusive to network control.”
These aren’t options that the average caller or user can have at their disposal without some special equipment and work on their network. So really it’s a moot point.
Try creating your IVR with Digits field 11, 12, 13, 14 where you would use A, B, C, D.
After Submit and Apply Config, copy the text for the IVR from extensions_additional.conf and add it to extensions_custom.conf. Change the context from e.g. [ivr-1] to [ivr-abcd] and change 11 to A, etc.
Create a Custom Destination with target ivr-abcd,s,1
and set your Inbound Route (or whatever) to go to ivr-abcd instead of ivr-1.
Whether or not the carrier filters the DTMF in question is immaterial; as stated previously, this is being built as a demonstration system. Its use (for now) is as a purely internally-accessible proof-of-concept.
Additionally, most software tone diallers are capable of generating the A, B, C, and D tones - and as this demo system is being built to interface with a physical device capable of generating those tones, this is far from being a “moot point,” as you put it.
I did a partial test:
Extension DTMF Signaling changed to in band audio.
Misc Application routes to IVR.
Call the feature code, hear prompt, play DTMF A into phone.
Get expected “We have not received a valid response.”
Log shows: pbx.c: Invalid extension 'A' in context 'ivr-1' on PJSIP ...
So I believe the modified IVR code should work as expected.
There is the rub, asterisk detects it and it will either by inband or by rfc or even RBS, but FreePBX php code also needs to parse it out as a regex to present to the ivr code and have an appropriate case destination.)
that would be generally [0-9*#A-D] but last time I looked the A-D bit was absent.
(Each dtmf digit is the sum of two sine waves at frequencies chosen to minimise false detection by human speech, so each one of the 16 possible values is effectively the vector sum of two base 4 represented sine waves using a simple lookup table. That is 1950’s technology we still use)
Absolutely. Asterisk will eat it up. But not FreePBX, you will have to hook into the IVR-n context but to an arbitrary point mapped to something between 0-9 or # or * because you only have 12 options not 16, call it a feature ; -)
(An A-D DTMF event neither generates 13-16 nor can ever be mapped/generated by an alpha overlayed 3x4 DTMF keypad)
