Hello,
Recently had a great bit of help (from Lorne) with the config for a context to speak back a calling extension where Feature Code *65 didn’t quite work for us.
The last post on that thread indicated that FPBX can do part of the next problem we’re trying to solve as we move off Cisco Call Manager and Unified Contact Centre Express:
But we’re stuck again, so here’s proper info to see if anyone (Lorne?) can help.
We’re on a campus, and have roughly 650 analogue extensions that must remain up during power cuts. These extensions are tested on a rota to make sure there’s no visible damage to the device, and that two way audio works fine (Feature Code *43 works nicely for this bit).
The rota for testing lives in a database that is accessed by going to device/location that is about to be tested, dialing an extension for the service and logging in with DTMF tones. The caller is asked (by UCCX) if there is visible damage to the phone: press button 1 records ‘yes’, button 2 records ‘no’.
The caller is then asked to speak after a tone to record a message, which is played back. If the audio is good press 1, if bad, press 2. Then hang up.
If there are problems a ticket is raised by email for that phone/location, and a timer is set for the next test in a month’s time.
*43 works nicely for the audio test. But is there a way FPBX can be made to work with our existing database for recording that a test was carried out, and whether or not a problem exists?
It is feasible that we’ll have to adjust our process and lose the database and the web front end, and simply rely on *43 and the tester noting down physical and/or audio problems manually in a notepad, and later sending an email to the HelpDesk. But it’d be nice to be retain the automation of the database as we currently have it.
Something on this link makes us think that there’s a way to achieve it, but we’re struggling to join the dots.
Thanks for reading
Nathan.