[Linphone-users] Handling of jitter buffer queue in oRTP.....

[Brian]

Hi,

I'm using oRTP (0.13.1 in production), and I have a strange behaviour that I 
can't work out....
Environment: SIP+RTP, G711 codec only with 20ms packets, no 'strange' stuff...

Between 2 endpoints, both using oRTP.

Using oRTP in non-scheduled mode, I have a thread that wakes up every 20ms, and 
 
calls the rtp_session_recv_with_ts() function. The 'remote' ts is calculated 
and 
updated at each 'tick' (20ms) by 160.

Equally, in this thread, I use the rtp_session_send_with_ts() with a ts 
incremented by 160 each 20ms send.

The oRTP lib is configured to have 0ms of jitter buffer and not use adaptive 
jitter adjustement, so I expect that the lib should hold no old packets, only 
the last one received.... (reducing delay is very important for us)

This all generally works very nicely when talking to other endpoints (oRTP and 
other suppliers...)

However, very occasionally, at a time T, the sender side seems to have a 
'network blockage' when sending packets, and for around 800ms no packets are 
sent at all. 
The receiver is cool with this (just treats as silence), and keeps incrementing 
its expected timestamp value each 20ms.
Then, the sender pipe unblocks, and all the missing packets are sent very 
rapidly, and then we resume normal operation (a send every 20ms). 

The received therefore gets around 40 RTP packets in a burst, all of which are 
in the past with respect to the 'remote_ts' given at each 
rtp_session_recv_with_ts() call.

Expected behaviour : the packets with a ts in the past, are discarded, and then 
packets that arrive with a good ts are passed as given.
Observed behaviour : the 'late' packets are queued, and given at each recv 
call, 
leading to the introduction of 800ms of delay in the audio which persists....

Maybe I have misunderstood the way the buffering works or the timestamp 
handling? Is this behaviour correct or not?

thanks!

Brian