RTPProxy version / package

[Jan Janak]

Jerome Martin wrote:
> Mark, Jan,
> 
> First of all, thanks for your kind answers and Happy New Year to you :-)
> 
> On Tue, 2007-01-09 at 13:57 +0100, Jan Janak wrote:
>> Mark, Jerome,
>>
>> The problem with rtpproxy versioning is that there isn't any. The CVS
>> repository for rtpproxy is here:
>>
>> http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/
>>
>> I have talked to Maxim already (the rtpproxy author) and he said he
>> would fix it, I introduced 0.2 and 0.3 with his permission meanwhile.
> 
> OK, I understand the situation. I agree that a CVS date tag would be
> less confusing (at least IMHO). I was in doubt, because I had lots of
> trouble with 0.3, and I was wondering if it was a different branch than
> 0.2 or just a more up-to-date version of the same branch.

  It was more up-to-date version of the same code.

>> I should have probably based the version numbers on the date of cvs
>> repository checkout, to avoid confusion.
> 
> Yep.
> 
>> We had some problems with UNIX domain sockets under really high load
>> where rtpproxy would block the SIP proxy server, that is the reason why
>> the default configuration file is using UDP sockets instead of UNIX
>> domain sockets.
> 
> OK, I'll default to loopback UDP too then. I just hope this doesn't add
> too much average delay vs. unix sockets.

  The delay caused by UDP sockets is negligible in most setups.

>> Let me know if you have any other questions.
> 
> Well, if you have any pointers to docs (commands, meaning of the A/B/C/D
> stats fetched from 'I', etc.), I could really use them. Also, I was
> wondering about kernel or /proc optimization that would help handling
> lots of small packets ...

  I wrote rtpproxy manpage some time ago and that's the only doc I am
  aware of. Try to ask Maxim Sobolev.

> Most of my problem, however, is about call quality : with only 50 RTP
> sessions on an underloaded bi-xeon 3.2Ghz and a stock sarge kernel, my
> users do notice a slight voice quality degradation (in G.729), without
> me being able to trace that to a cause other than adding rtpproxy in the
> path. Also, with the 0.3 version, I had lots of "rtpproxy return invalid
> port number 0" under a not-so-heavy load of maybe 10cps for a total of
> 50 to 100 sessions - could that be related to using unix sockets instead
> of UDP ?

  There is a port range defined in the sources and rtpproxy would
  allocate ports in that port range only. Make sure you do not run out
  of available ports (try bigger port range and recompile rtpproxy). I
  don't think this problem is caused by UNIX domain sockets.

     Jan.