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

[Dragos D]

Hi Brian,
The best approach would be to look at the code :-)
It maybe something with the 0ms you configured instead of another minimum.
Or maybe the oRTP jitter just takes care of the jitter ( packet
reordering), not the delays.
Dragos

On Wed, Dec 28, 2011 at 3:55 AM, Brian <address@hidden> wrote:
> 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
>
>
>
> _______________________________________________
> Linphone-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/linphone-users