Hello Vikram,
Network jittter may have an effect on how much payload is available to be sent. Take a look at this thread: http://lists.rtpproxy.org/pipermail/users/2008-August/000060.html Check the value of POLL_LIMIT on the version of rtpproxy that you are using.
If you are able to run the same test identically (using sipp with media for example) it would be interesting to see what kind of results you will have: - running the same test several times and analyze the jitter on both incoming and outgoing rtp stream; - running the same test (with an increased POOL_LIMIT) several times and analyze the jitter on both incoming and outgoing rtp stream.
If this doesn't have any effect, then the code needs to be instrumented to see what exactly is going on (by adding specific probes for your specific tests).
It would be interesting to see your results.
Regards, Ovidiu Sas
On Sat, Sep 18, 2010 at 5:47 PM, Vikram Ragukumar vragukumar@signalogic.com wrote:
Ovidiu,
If you have a codec that has silence suppression enabled, then you may get all kind of arbitrary lengths for packets (as silence suppression may kick in at any time). Disable silence suppression on both ends and retest. If you are still seeing variable length packets then there might be a problem.
Thank you for your reply. That is a good point that you raise. However, we did ensure that Silence suppression was disabled in all our tests.
Upon further investigation we have found that occasionally there is a "timeout" (corresponding to the instances when proxy sends a packet with size less than what was requested of the resizer), i.e. the following check in rtp_resizer.c (rtpproxy v1.2.1) fails (line num 230)
"if(this->nsamples_total < this->output_nsamples && ts_less(ref_ts, this->queue.first->ts + this->output_nsamples + 160))"
The condition to the right of the logical 'and (&&)' seems to fail. We notice that this failure happens immediately after the list of previously enqueued packets has been emptied.
Is this caused by network jitter ? Also, why is there a 160 that is added in the above check.. would increasing that cause fewer timeouts ?
Thanks and Regards, Vikram