[SR-Users] Change in RTP Payload time on the fly

[Ovidiu Sas]

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 at 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
>
>