OPENSER Integration –- USD$200.00
-
I am offering a $200.00 dollars bounty for anyone who can integrate OPENSER 1.1.x into PFSENSE.
I want to at least be able to edit the openser.cfg file, start/stop the openser process and if possible be able to read the log file through the GUI. Also, I would like to be able to define the listen port through the GUI, and it should be able to update the firewall rules to allow traffic flow.
Candidates please email me at lestat215@hotmail.com for details.
-
sipster did not answer to my PM and since there's no official OpenSER 1.1.x package we should consider closing this bounty if sipster does not reply to his own forum message within seven days.
Regards
Daniel S. Haischt -
I never received a private message. What do you mean by "there's no official Openser 1.1.x package"?
I meant Openser 1.1.x from www.openser.org.The offer still stands, contact me if you interested.
-
Hello,
I did send you an email message as requested by you in your initial forum post.
pfSense is heavily based on FreeBSD packages. Having a FreeBSD package or beeing able to utilize an OpenSER package for FreeBSD would greatly simplify the process of integrating OpenSER into pfSense.
If you search for OpenSER at http://www.freebsd.org/cgi/ports.cgi?query=openser&stype=all, you may figure that at the time there only exists an OpenSER 1.0.1 package.
So I am not sure whether USD $200.00 are enough to legitimate the creation of a complete new OpenSER 1.1.0 FreeBSD port/package (creating a port is required to generate a binary package for FreeBSD).
At the time I really have no idea how many OpenSER configuration option should be configurable via the pfSense webGUI. Thus I would like you to attach an example OpenSER config file to this forum topic.
Regards
Daniel S. Haischt -
OK. In that case, version 1.0.1 will be good enough. As far as configuration options, OpenSER has too many options.
That is why I requested to be able to edit the openser.cfg file from the GUI. If you think that you can design a GUI for most of the options, then go for it.I'll be content if you can accomplish what I asked for in the original post.
-
Can you attach an example OpenSER config to this forum topic, please?
-
Which OpenSER features should configurable?
-
AFAIK OpenSER supports modules/plugins. Are you requesting webGUI configuration support for a particular module as well?
I am not familair with OpenSER, hence I am not able to say whether it would take me a day or even a week to get everything going. Do I need any special hardware to do the integration tests?
Regards
Daniel S. Haischt -
-
You may find sample config files here: http://voip-info.org/wiki/view/OpenSER
You need to scroll down to the "Deploying OpenSER" section. I am particularly interested in the Nathelper/rtpproxy implementation.I am not particularly interested in any modules at the moment, but if I find something that I might use I will let you know and maybe we can negotiate that part too.
In order to test this, you need two VoIP SIP Phones and a SIP server (i.e. Asterisk). One phone has to sit behind a NAT translated network, the other may or may not. Since SIP does not work behind NAT, OpenSER will take care of the protocol translation. If you can get the two phones to have two-way audio, then OpenSER is working.
Here are some diagrams of what OpenSER should accomplish. http://freshmeat.net/articles/view/2079/
In our case the SIP server sits behind the PfSense/OpenSER box and the internal phone connects to the SIP Server. The external phone is on the Internet and attempts a SIP connection to the internal phone using OpenSER as a SIP Proxy.I will get you one of my sample configs, but the sample files from the link above should be good enough to get you started. Let me know if you have more questions.
-
Since SIP does not work behind NAT, OpenSER will take care of the protocol translation.
manny people have sip working beheid a pfsense nat using the static nat port option
-
SIP works but not the way I want it. I realized that in my last post the information is not as clear as it should be.
In my last post, I meant that the external phone is on the Internet and needs to register into the internal SIP server just like the internal one.This scenario does not allow for the RTP ports to be translated properly and ends up with the external phone having no audio at all or at best one-way audio when placing or receiving a call. This issue is solved when the SIP server is paired with OpenSER as a proxy to handle the RTP translation.
On the external phone's SIP configuration we would use:
SIP Proxy: pfsense.externalip:5060–> forwarded to the SIP Server using port 5060
SIP Outbound Proxy: pfsense.externalip:5065OpenSER process using port 5065I hope this helps clear out the confusion.</pfsense.externalip:5065></pfsense.externalip:5060>
-
Maybe repairing the siproxd package that we already have in the package repository would work too? http://siproxd.sourceforge.net/
-
I tried to use siproxd but I found it a little confusing (if I am not mistaken, siproxd tries to accomplish the exact opposite of what I want), I am willing to try it though if it will solve my problem. However, I would rather pay for the OpenSER integration since I know that OpenSER does work well. I would consider siproxd as an interim solution while OpenSER is being integrated.
-
Right, siproxd is for outbound SIP… Clients behind a nat'd device needing access to a SIP proxy on the Internet.
OpenSER would allow for SIP traversal inbound to an internal SIP Proxy. That proxy may then route to any internal IP phone which is where the 1 to 1 NAT breaks down when a true internal SIP proxy is involved. This type of 1 to 1 NAT setup may work fine for an Asterisk type box if you want to leave all of your ports SIP ports open to it because Asterisk will stay in the communications path (gack).
Another good candidate might be OpenSBC (http://www.opensourcesip.org/).
sipster is right, this is something drastically needed...
-
Okay I'll go with OpenSER for now as requested by sipster. Cause you stated that this is a drastically needed package (or feature even), I'll do a FreeBSD port of OpenSER 1.1 if someone is willing to put another USD $200 on top of the initially offered USD $200.
I'll have to setup a pfSense RELENG/1.0.1 developement system, because if I understood you correct you are going to use OpenSER on a pfSense 1.0.1 RELEASE system (correct me if I am wrong). So anybody interested in such a package/feature has some time to think about the additional USD $200.
OpenSER pfSense package details (as requested):
-
One HTML textarea field to be able to edit the OpenSER config file
-
One HTML textarea field to display OpenSER's log file (or an extra tab at Status->System logs)
-
Possibility to start/stop OpenSER at Status->Services
-
One HTML text input field that allows to provide a custom listen port on which OpenSER will listen on
-
FW rules are getting added on the fly if activating the package
Regards
Daniel S. Haischt -
-
That is correct. I will be using a 1.0.1 RELEASE system.
Your package checklist is exactly what I am looking for. Go for it.
-
openser 1.1 port is at:
http://openser.cvs.sourceforge.net/openser/sip-server/packaging/freebsd/?pathrev=rel_1_1_0 -
Great!
Daniel,
Does this help you integrate the OpenSER 1.1 package with PfSense?
I definitely prefer the 1.1 package. -
Daniel,
Does this help you integrate the OpenSER 1.1 package with PfSense?
I definitely prefer the 1.1 package.Yes, I guess I will move the port files over to the pfSense port repo, cause as it seems some files are still missing. But it's a beginning…
Regards
Daniel S. Haischtp. s. If the OpenSER 1.1 FreeBSD port author reads this: Please submit your port to the official FreeBSD ports repository ;)
-
extra, extra ;-)
regarding your p.s.
OpenSer port author: Jesus Rodriguez jesusr@voztele.com- Torsten/jesusr@voztele.com -
How are we doing on this one?
I, too, need either siproxd or better yet OpenSER so SIP will work reliably behind NAT. Many SIP clients do figure out how to work behind NAT but occasionally calls have one-way audio and such and we can't really rely on their built-in NAT traversal when dealing with business-class clients whose phones need to work reliably all the time.
-
@tog:
How are we doing on this one?
I, too, need either siproxd or better yet OpenSER so SIP will work reliably behind NAT. Many SIP clients do figure out how to work behind NAT but occasionally calls have one-way audio and such and we can't really rely on their built-in NAT traversal when dealing with business-class clients whose phones need to work reliably all the time.
Great! So commit to the bounty and raise the bar. I am not working on this one but this entire bounty thing was meant for MULTIPLE parties to show their support with their checkbook.