(right click to enlarge in a separate window)
After laying the groundwork and creating the required software for visualizing IP inter-packet spacing in part 1 and part 2, I could finally answer myself the following question: What kind of impact do cellular network handovers have on the inter-packet spacing of an over the top (OTT) voice call and hence on the jitter buffer and ultimately voice quality? Theoretically, handovers in LTE and 5G cellular networks are break before make. This means the connection to the current cell is cut and only afterward does the UE contact the new cell. According to an Ericsson paper, this procedure takes around 50 to 90 ms. So if this is the case, one should see it in the inter-packet spacing.
In the case of a Conversations messenger app voice call, one voice packet arrives every 20 milliseconds over a good channel. So if a handover takes 50 to 90 ms to execute, one should see that in an inter-packet spacing graph (see part 2 of this series). And indeed, this is the case as shown in the graph above which was produced as follows:
The graph shows IP voice packets of a WebRTC call with the Conversations messenger app arriving at a stationary device from another device I was carrying between two rooms. The two rooms are covered by different LTE/5G ENDC cells of the LTE/5G ENDC network outside, so it’s easy for me to trigger handovers this way. While I was tracing the voice packets on the stationary device, I hooked up a mobile device tracer on the device I was carrying between the two rooms so I could observe handovers and their timings. I then compared the observed handover times with the times of the outlier packets I had marked with red circles in the graph above. The result: A perfect match!
So there you go, handovers made visible in the speech channel!
Next question: Can those handovers actually be heard in practice? At least I couldn’t hear them, the jitter buffer on the receiving end effectively compensated for it. Which is quite interesting in itself, so I have to read up a bit on how that is actually done by the WebRTC jitter buffer implementation.