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

Vikram Ragukumar vragukumar at signalogic.com
Tue Sep 21 01:48:54 CEST 2010


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.



More information about the sr-users mailing list