We recently completed some touch-up programming on a group of systems belonging to a recently acquired customer and some odd things started happening that they blamed on the changes in programming. One issue was an ‘operating characteristic’ in the Telstra SIP Connect lines that, in conjunction with Apple iOS 11 causes calls to bounce to the backup answering point because the phone system rejects the call because the received data falls outside what it is expecting. The fix for this is very simple.
We also supplied a ruggedised cordless phone for testing and it was supposed to go to Site Y. Recently Site E has started having problems with incoming calls going to a strange recording advising the call not being able to be transferred after about 4 rings. Announcements are set up to kick in after 5 rings and the voicemail to the Main hunt group is turned off. The prompt sounds like an Avaya recording but the wording I have never heard before. It almost sounded like the system had got switched into night service but the customer said the night service button wasn’t on and the clock was correct as night service also occurs on a timed basis.
We have remote access to the Avaya through Team Viewer to one of the PC’s. Unfortunately that PC has recently been changed and the Avaya software didn’t come across so the only way to look at the programming was through the Web Manager. System Status was not available, nor Monitor and Java is not installed on the machine. Due to the slow Internet it is not possible to install it either.
Being blind to what was happening when a call was delivered, one of my guys attended site on the way past, installed the Manager Suite but used his own laptop to run System Status due to the lack of Java.
On an incoming call it was immediately clear what was happening – the cordless phone for Site Y had been installed at Site E and the answering machine left on so it was answering the call after 4 rings. The prompt must have been recorded by the same artist because it sounds identical to the prompts used in the Avaya system.
This is another example of how methodical fault finding locates the problem and assumptions can send you off on the wrong track.
So many times I’ve ended up making an assumption at the start of troubleshooting and if it’s wrong it throws EVERYTHING out. All makes sense at the end but can be a very frustrating troubleshooting session when nothing makes sense.