I’m a big fan of the movie Interstellar. Aside from thoroughly enjoying the flick, a lot of the science behind it was well researched. There is a phenomenon that occurs in our analogue world due to the curvature of spacetime that Einstein proposed with General Relativity. The closer an observer is to a large mass, they will experience time differently than an observer that is further away from it due to relativistic effects of the gravitational differences for each observer. Basically there is no universal clock and it depends on where the observer is relative to what is being observed. This was a critical consideration for the teams in Interstellar as they experienced time differently the closer they got to larger planets and black holes! Your VoIP phone can learn a lesson from this.

Movies aside, the GPS satellites in our planet’s atmosphere experience this and have programming built in to correct this difference between Earth and their orbits which allows for them to stay in sync. Without this time correction we would experience errors of up to 10 KM per day when trying to navigate via GPS and this time dilation effect is termed Clock Drift.

Interestingly enough (and physics aside) a similar problem can occur in the digital world which is commonly referred to as Clock Skew which can impact VoIP phone systems.




Clock Skew can affect call quality especially when phone systems are virtualised. There can be various reasons packet timings are affected, but most commonly it is when the clock time of a hypervisor does not beat at the same rate as a VoIP PBX system.

It is tricky to diagnose unless you know how to spot it, and it can be easy to blame the PBX as the culprit as it can magically appear out of thin air. Common experiences from an end user perspective will be random blips in audio on a phone call, and potentially issues having a digital receptionist recognise DTMF tones. Repeating the fault and getting a packet capture will reveal a couple of key things to diagnose this.

Firstly, looking at a VoIP stream analysis within a tool such as Wireshark (my favourite tool of choice) will show moments of inserted silence where the audio has blipped. Playing back the stream will also allow you to hear the blip on the call (provided they aren’t using a codec that encrypts the stream). Opening the capture in an RTP view within Wireshark and jumping onto a stream analysis will show the problem immediately. Generally, of note will be the jitter value is scary and the analysis will actually show the clock skew value. (Hopefully not 10 KM’s worth like with the potential GPS satellite issue!)



You may also notice that the odd “Incorrect Timestamp” message is present as well as a flurry of packets after the audio blip. Out of 90% of the cases I’ve seen this has been due to incorrect NTP settings on the virtual machine of the PBX system which is easily remedied by setting them to the hypervisor’s NTP server. This will be set differently depending on whether the system is Windows or Linux based. Linux based systems generally will require for NTP software to be installed and Windows Hyper V systems need integration services installed. For assistance with setting this up, 3CX have an excellent article with step by step instructions.