OPENSER Integration –- USD$200.00
-
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.
-
I'll work on this bounty! I can assure one think and I think any other dev can too: I won't spend my money on junk food or on a cruise or whatever but on test hard- and software and on books which may help to improve the pfSense product.
So if you need a particular feature too, start contributing money to the particular bounty. The money won't be wasted!!!
Cheers
Daniel S. Haischt -
Ok, I just wanted to put the question out and see how much you were looking for to get it done.
You said earlier an additional $200 would be enough for you to get going, is that still the case?
-
@tog:
You said earlier an additional $200 would be enough for you to get going, is that still the case?
Yes, including OpenSER 1.1 support.
Regards
Daniel S. Haischt -
Ok, I'm in. Let's do it.
I commit $200 to this bounty to get a nice basic working OpenSER package for pfSense to achieve my intended purpose of outbound proxying SIP clients located behind a pfSense NAT gateway.