[Serusers] Re: [Serdev] Porta Software vs. AG Projects [open letter]

Andrei Pelinescu-Onciul pelinescu-onciul at fokus.fraunhofer.de
Thu Mar 25 12:19:14 CET 2004


On Mar 25, 2004 at 09:04, Adrian Georgescu <ag at ag-projects.com> wrote:
> My answer to this open letter is:
> 
> AG Projects developed a NAT traversal solution for SER and released  
> the source code under GPL license. The architecture, capabilities and 
> functionality of the software bares no resemblance  with existing 
> nathelper/rtpproxy software.
> 
> - Local or remote installation
> - Load balancing and redundancy using DNS SRV records
> - Handles video or multiple audio streams
> - Suports chained Media proxies and other SBCs
> - Display active sessions from multiple servers
> - Accounting of network traffic
> - Independent of SER version

Ok. let's try to stick to the mediaproxy ser module. Most of the things
you said above apply only to your media relay.
BTW: nathelper is independent on the ser version, you can use the
unstable cvs version with a stable ser cvs without any problems.

The ser module resembles a lot nathelper in functionality. It has some
extra features like usage of a  list of user agent names to decide
whether rtp is symmetric (nathelper uses a different approach, a flag in
the force_rtp_proxy), decides whether sip is symmetric or not (again a
list of UAs read from a file) and changes or not the port in Contact:. I
think its main feature over nathelper is handling of multiple streams.
Nathelper features not present in mediaproxy are ipv6 support, bridging
mode, more ser config flexibility (like query only mode, good for
re-INVITEs).

mediaproxy also uses a different protocol to speak to its media relay.
It includes domain names, all sdp streams info, user agent a.s.o.

So you cannot say the mediaproxy module is not similar in functionality with
nathelper. From my point of view there are only minor changes (like a
lot more parameters send to the media relay). But even the way command
are sent to it is the same (opening, connecting, writing and closing an 
unix stream socket each time a command is sent [which is not a very good
ideea IMHO]).


Let's concentrate on the module and whether or not this is a (C)
infringement and how to solve this problem in an amiable way.


Andrei




More information about the sr-users mailing list