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

[Brian]

Dragos D <ddragos77 <at> gmail.com> writes:
> 
> Hi Brian,
> The best approach would be to look at the code 

Well, I did look at the code... 

> It maybe something with the 0ms you configured instead of another minimum.
But I looked again... and it does seem like setting a jitter buffer size of 0ms 
does cause a specific behaviour for the receiver....

In the case where 
session->rtp.jittctl.jitt_comp_ts==0
it uses a specific rtp_getq() function called rtp_getq_permissive() which does 
not look for the "newest packet with that is just older than the requested 
timestamp and discard any older ones", but just returns the oldest timestamp it 
has...

This sounds like my behaviour... I will set my jitter compensation to 10ms and 
see how it goes....

cheers

Brian

Dragos D <ddragos77 <at> gmail.com> writes:
> 
> 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 <brian.wyld <at> eloquant.com> 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
> > Linphone-users <at> nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/linphone-users
>