Ovidiu, 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, 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.