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