Could someone please check the attached system log file?
A Polycom certified technician has been to site and confirmed that the equipment is in working order. Unfortunately, this is on another continent and we are still experiencing frequent call failures. I'd like to rule out hardware errors prior to troubleshooting network issues.
Solved! Go to Solution.
The quality of your network connection seems to be too bad. Check packet loss and jitter from Call Statistics screen.
Thanks for the reply. The line has been upgraded to a 20mb DSL which hasn't helped much with the latency or packet loss. The system is based in China and we're having difficulty querying the service with the ISP.I was wondering if the high temperature might contribute to the fault as well?
The DSL d/l speed may well be 20MB but what is the upspeed? Google DSL Speed Test for available resources.
Rumour is that R&D installed a Temp Sensor detect & intentionally set the threashold a bit low to gather data. A high temp warning is therefore, not necessarilly a fault.
IF the codec holds a call in its local LAN up for a reasonable period of time, it could be a port timeout on your (or their) firewall.
You are right, the highest displayed temp at 58 deg. seems not being a cause. My opinion about the origin of problem is based on the detected gap in frames and missing packet. The packet loss seems to be about 50% or more, for example:
2015-05-20 09:56:03 INFO avc: hd: DSP: Detected gap in frame number prev 235 curr 238
2015-05-20 09:56:03 INFO avc: hd: DSP: Detected gap in frame number prev 238 curr 240
2015-05-20 09:56:03 INFO avc: hd: DSP: Detected gap in frame number prev 240 curr 243
2015-05-20 09:56:03 INFO avc: hd: DSP: Detected gap in frame number prev 245 curr 251
You should not see the high temperature alarm if the codec is properly installed. Which means it has full air flow around the codec, especially bottom to top and the ambient temperature does not exceed the specifications on the data sheet.
We have found installation issues contribute to the high temperature alarms. Such as installing in a closed, non-ventilated space or installing in an upright position without the 'legs' installed which halted air flow through the codec.
A few things.
1. The Polycom endpoints shouldn't be disconnecting calls simply due to packet loss in RTP. For example, you may have 100% loss in an RTP stream, but that should not cause the system to initiate a call disconnection.
2. As pointed out, there are significant packet loss in the RTP stream being observed by the local HDX 7000 system.
3. However, according to the log snippet, from the local HDX 7000's point of view, it's the incoming H.225.0 ReleaseComplete which initiated the call disconnection. In other words, it's not the local system which initiated the call disconnection.
Hope this helps.
Thanks for the reply. So, both endpoints register on the gatekeeper and one of them will initiate the CloseLogicalChannel and EndSessionComand using H.245 and then via H.225 the same endpoint sends ReleaseComplete?
In the current scenario it's a bit odd because the problematic endpoint is the only device that experiences the described disconnects. It also only disconnects on international calls. The endpoints which connect with it don't experience problems with any other calls.