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

2010-09-20 Thread Vikram Ragukumar
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/60.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

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

2010-09-19 Thread 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/60.html Check the value of POLL_LIMIT on the version of rtpproxy that you are using. If you are able to run the same

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

2010-09-18 Thread Pranav Desai
Hello, Thank you for your comments. My answers are inline. > Hello, > > ptime and also the z flag are ms values, so a values of 6 or 8 ms are not > the recommended length of time, it should be an integer > multiple of 5 ms. I havn't yet a look the the source, but the nathelper > doc > say ZNN, m

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

2010-09-18 Thread Vikram Ragukumar
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

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

2010-09-18 Thread Ovidiu Sas
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.

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

2010-09-18 Thread Andreas Heise
Hello Pranav, ptime and also the z flag are ms values, so a values of 6 or 8 ms are not the recommended length of time, for G729 it should be an integer multiple of 10 ms. I havn't yet a look the the source, but the nathelper doc say ZNN, maybe only the 12 is taken from your 120? But in fact the d

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

2010-09-17 Thread Pranav Desai
Hello, We have a proxy server setup that runs Kamailiov3.0.1 + RTPProxyv1.2.1. Nathelper support has been enabled in Kamailio. On a certain route, we call force_rtp_proxy("z120"), i.e. with resizing parameter 'z' and argument 120ms. During a call where endpoints have negotiated the use of G729,