[Linphone-developers] Receiving silent packets from ortp

[Petr Kuba]

Hello,
we have problems using ortp to receive rtp streams. The received streams 
often contain silent packets inserted by ortp. It looks like we do not 
understand several things in the ortp behavior. Let me describe our 
experiments.

First we used scheduling and blocking mode:
rtp_session_set_scheduling_mode (rtpSession,1);
rtp_session_set_blocking_mode(rtpSession,1);

However, it looks like rtp_session_recv_with_ts() is not blocking as it 
should be. If I understand it correctly this method should block until 
time given by the timestamp is reached. Am I right? In our case the 
method does not wait and immediately returns packet full of silence 
event if it is called too early. Does anyone know what is wrong?

Then we tried to use session_set_select() (with scheduling, of course) 
for waiting before calling rtp_session_recv_with_ts() but result was the 
same. This method was not blocking until given time. In this case, could 
someone explain us the following statement from the documentation of use 
session_set_select()?

"The first set is interpreted as a set of RtpSession waiting for receive 
events: a new buffer (perhaps empty) is availlable on one or more 
sessions of the set, or the last receive operation with 
rtp_session_recv_with_ts() would have finished if it were in blocking mode."

How can session_set_select() know when would have 
rtp_session_recv_with_ts() finished? It has no information about 
timestamp that will be provided to rtp_session_recv_with_ts().

Finally, we decided to use our own "scheduling": we wait until time for 
the next packet is reached. In this case we achieve the best behavior - 
we receive the smallest amount of silent packets. However, since we are 
testing on local network I would expect to receive no silent packets. 
And we receive some although we call rtp_session_recv_with_ts() after 
the timestamp passed.

So, my basic question is how can we convince rtp_session_recv_with_ts() 
not to return silent packets? Worse, it looks like that when ortp 
returns silent packet for some timestamp and then receives this packet 
it returns it in the next iteration. This makes the rtp stream "longer" 
and thus delayed. Could someone help us with this issue?

In summary, we would appreciate some more detailed description how 
receiving rtp streams works including description of the jitter 
algorithm behavior.

Thanks a lot for responses.
Regards,
Petr Kuba

--
   Petr Kuba, Project Manager
   OptimSys, s.r.o
   address@hidden
   Tel: +420 541 143 065
   Fax: +420 541 143 066
   http://www.optimsys.cz