I've been testing reConServer (using recon, reflow, sipXtapi) in various environments. On one particular DSL connection, packets from the handset to reConServer are occasionally delayed for up to a second.
When reConServer receives the packets, the jitter buffer should probably drop some of them because they are too late.
Instead, it plays them back really quickly, the other party hears a "fast forward" sound effect. They should just hear a moment of silence and then the resumption of normal audio.
I had a look in the code and found this buffer in reflow/Flow.cxx:
#define MAX_RECEIVE_FIFO_DURATION 10 // seconds
#define MAX_RECEIVE_FIFO_SIZE (100 * MAX_RECEIVE_FIFO_DURATION) // 1000 = 1 message every 10 ms for 10 seconds - appropriate for RTP
I searched for information about the sipXtapi jitter buffer and found the following comments from Dan Petrie in 2014:
"The vanilla, open source version of sipX does not have an adaptive jitter buffer or a very robust packet loss compensation algorithm. It you have network situations where you have any sort of packet loss or jitter, you probably will want to consider using SIPez's proprietary media engine plugin (SME) for sipX. With SIPez's SME, packet loss is not noticible to most people with up to 5% packet loss which is a pretty huge amount of loss for most network situations. SIPez's SME also minimizes latency which can build up sometimes with just the pure open source sipX solution. SIPez's SME is a pay for/commercial plugin."
This raises a few possibilities:
- is the Flow.cxx buffer too big?
- there are various jitter buffer implementations out there, can we link any of them with sipXtapi?
- will SIPez offer their more advanced jitter buffer under a dual license, e.g. GPL for exclusive use in open source projects?
- is this another reason to look at other media stacks, for example, the WebRTC media stack from the Google Chrome?