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

Ovidiu,

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.

Thank you for your response. Further analysis has revealed that the "timeout" we were observing at rtpproxy seems to be legitimate. Following is a link to a wireshark capture for a test call, showing a large interarrival time on the input side of rtpproxy's resizer.

http://signalogic.com/images/rtpproxy_resizing_ptime_12.jpg

A brief description of our test system is below

G729,ptime = 2 -----> G729,ptime = 2 ------------ ----- ---------- ------------------ -------- |SIPSoftphone|--|proxy|--|VoIPSwitch|--|Terminationgateway|--|Landline| ------------ ----- ---------- ------------------ -------- G729,ptime = 12 <----- G729,ptime = 2

RTP resizing is performed going in the direction from the landline to the softphone. During the course of a 1 minute call, on 4 or 5 instances, rtpproxy sends to the softphone packets with duration less than 120ms. From the wireshark capture it can be seen that these are legitimate time outs because, rtpproxy does not receive packets from VoIPSwitch on time, to be able to construct a 120ms payload.

Has anybody else seen this behavior when using VoIPSwitch or Asterisk or another B2BUA ?

Thanks and Regards, Vikram.