We have succesfully installed the Dialogic HMP software and the secondary Syntellect Envox Communications Server (with the help of Bressner & Co).
The one thing we are missing right now, is the right configuration (which includes a reinstall of the primary server).
So, let’s go for it…
Next week.
We will re-install all components and establish a proper redundant configuration because the root causes of the remaining errors could not be found and nobody is bold (or crazy) enough to make further changes on the systems without fearing another crash…
last 2 weeks were really good – no crash no unexpected downtime. Although the errors are not fixed. wireshark is waiting …
At approximately 4 o’clock morning the NIC died resulting in a service outage. The Envox server itself was up and running. Our hosting crew fixed the NIC problem by activating the secondary NIC. Unfortunately the Dialogic HMP license file is bound to the MAC address of the NIC.
Changing the Dialogic license file permanently is not free of charge, even though we are no longer able to use the “old” licenses any more. Fortunately the guys at Bressner, our local support partner for Envox/Syntellect, offered to fix the license issue free of charge.
After creating the license file, uploading and activating it, the SCP started without any problems and the servicelines were available once again. We had an outage of approx. 12 hours due to this issue.
Once again, thanks to the guys at Bressner for their non-bureaucratic help in this matter.
The notorious HMP error occurred again.
We restarted the service immediately after receiving the error message via the Syntellect Alarm Center. It’s now up and running.
Wireshark Logging, which is supposed to support us in identifying the HMP error, is problematic as it constantly runs out of memory, even though the machine is sufficiently equipped with ROM and RAM. Alternatives to Wireshark are welcome.
Thursday at aprox 10 pm in the night the HMP module lost connectivity to the sip registrar. Consequently the system rejected all calls. Due to a mail sending problem and no reaction of the envox support (who received the error mail) the platform was off line for several hours again. This is a known bug which seems not to be resolvable.
We sent detailed logs to Envox support again for analyses.
Although we got confusing answers regarding the problematic deployment of MRCP for a onboard resource everything seems to be ok.
MRCP: - we are not driving a MRCP-resource – we do not operate any onboard or off-board resource like TTS or ASR. Hopefully the system support was on the appropriate server (??)
To get a better idea about potential problem sources Envox support is analyzing the platform environment.
… 3 unexpected and never seen errors were recorded (DOS
error during gc_Close call to close Dialogic resources), and at the 4th call
the resource engine completely hanged, and was finally killed by the Server.
These errors should not occur and we have never seen them before.
After 10 hours of analyzing the error logs Envox support successfully restarted the engine and we are back on air again.