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 _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
