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 > _______________________________________________ Linphone-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/linphone-users
