[Bug 203407] [NEW PORT] net/opensips

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203407

            Bug ID: 203407
           Summary: [NEW PORT] net/opensips
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Individual Port(s)
          Assignee: freebsd-ports-bugs at FreeBSD.org
          Reporter: euan at potensol.com

Created attachment 161472
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=161472&action=edit
shar file for net/opensips

New port for latest version of stable branch of OpenSIPS. 
http://www.opensips.org/

This port was tricky to make because OpenSIPS make files do not use autotools
or cmake, or anything similar. The user is intended to run "gmake menuconfig"
and select the modules to build and any other build time options from the
ncurses style menu. Therefore, I had to replicate the end result using
FreeBSDs' make mechanisms. The port Makefile takes the port OPTIONS to generate
a gmake Makefile using sed (string replacement). I had to overide
"do-configure", "do-build" and do-install" because it was not possible any
other way. Likewise, gcc and gmake are used because OpenSIPS requires them to
build properly (from my experience).

I have been running the port in production for many weeks now, without any
known problems.

NOTE: I have found running many versions of Kamailio (sister fork of OpenSIPS)
and other versions of OpenSIPS to have the service crash randomly over time
when used in jails. Not tested outside of a jail. This version is super stable
on at least 10.1 amd64. However, I have found the main configuration file
(opensips.cfg) can also cause crashes under certain configurations. Basically,
if everything is right, it is rock solid stable. But otherwise it can be quite
flakey. I can't say if this is the case under Linux, the primary target
audience. I am attributing many of the crashes to either memory leak(s) or bad
memory management. It may just be the FreeBSD VMem system that it affects.
Nonetheless, this port with my sample config is very stable.

-- 
You are receiving this mail because:
You are the assignee for the bug.