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
