I am considering using FreeSWITCH as a replacement of our (rather crappy, outdated and buggy) sip proxy system, and have the following system setup on the server: * eth0 faces the external Internet interface, *but* it does not have a public IP address (it has a private one given to it by my ISP's DHCP server); * eth1 faces our internal network (say 10.1.1.0/24); * tun0 serves all mobile smartphones and connects to the internal network (it has a different ip range, say 10.1.2.0/24) - they are all connected via the Internet using OpenVPN; I would like to configure FreeSWITCH as a local registrar and ask it to handle internal calls between ourselves (eth1<->tun0). I would also like to use one external VOIP provider to which FreeSWITCH registers on startup. This also needs to have all NAT-related issues dealt with as well (hopefully by FreeSWITCH, if possible). I would also need to emphasise that FreeSWITCH *cannot* just listen on any (public-facing) interface port in order to receive calls from the external provider, simply because my ISP won't allow it (i.e. I can't just "open" that port and hope that someone will contact me - the connection needs to be initiated by our server for incoming call to get routed through). The purpose of registering this external account is so that both the smart phones (tun0) and the internal net (eth1) users could use this account to make external calls (starting with "0"). Obviously, I need these calls to be routed properly via the external VOIP account. In addition to that, I would also need to receive calls from that external account to a nominated internal one (say on extension 20). Could this be done relatively easily in FreeSWITCH? A question about binding: in order to be able to use both tun0 and eth1 interfaces so that FreeSWITCH serves the calls from both eth1 and tun0 devices/networks, is it possible to instruct it to bind on different IP addresses (on tun0 and eth1 respectively) in order to serve calls to/from these networks? I do *not* wish to bind to 0.0.0.0 - just use the interfaces I am interested in - tun0 and eth1 in my case. If all of the above is possible, do I have to mess about and configure SNAT/DNAT separately and use sip kernel module "helpers" etc (I *do* have the routing set up properly though - that I am sure works 100%) or is FreeSWITCH perfectly capable of setting it all up for me? One final query: is there a decent distribution source package of FreeSWITCH, which I could take and then use it to build a binary package (I use Fedora on all of our machines). I need this, because all of our images are built using the rpm packaging system and I cannot just "fetch the latest git", compile and install FreeSWITCH - I need it packaged, so that the image builder picks it up and distributes it to the machine concerned. I checked the SUSE repository (as instructed on the FreeSWITCH wiki), but found 2 packages, both of which cannot be build due to errors! Many thanks in advance!
Welcome to FreeSWITCH! Comments inline... -MC On Wed, Feb 8, 2012 at 3:50 PM, Josh <mojo1736@privatedemail.net> wrote:
I am considering using FreeSWITCH as a replacement of our (rather crappy, outdated and buggy) sip proxy system, and have the following system setup on the server:
* eth0 faces the external Internet interface, *but* it does not have a public IP address (it has a private one given to it by my ISP's DHCP server); * eth1 faces our internal network (say 10.1.1.0/24); * tun0 serves all mobile smartphones and connects to the internal network (it has a different ip range, say 10.1.2.0/24) - they are all connected via the Internet using OpenVPN;
I would like to configure FreeSWITCH as a local registrar and ask it to handle internal calls between ourselves (eth1<->tun0). I would also like to use one external VOIP provider to which FreeSWITCH registers on startup. This also needs to have all NAT-related issues dealt with as well (hopefully by FreeSWITCH, if possible). I would also need to emphasise that FreeSWITCH *cannot* just listen on any (public-facing) interface port in order to receive calls from the external provider, simply because my ISP won't allow it (i.e. I can't just "open" that port and hope that someone will contact me - the connection needs to be initiated by our server for incoming call to get routed through).
But calls will be sent to FreeSWITCH by some device, correct? If it's good old-fashioned SIP then FreeSWITCH will handle it just fine.
The purpose of registering this external account is so that both the smart phones (tun0) and the internal net (eth1) users could use this account to make external calls (starting with "0"). Obviously, I need these calls to be routed properly via the external VOIP account. In addition to that, I would also need to receive calls from that external account to a nominated internal one (say on extension 20).
Could this be done relatively easily in FreeSWITCH?
"Relatively?" Of course! It's relatively easy for someone with some experience. I highly recommend that you ask consulting@freeswitch.org for professional assistance if you are not comfortable doing this all by yourself.
A question about binding: in order to be able to use both tun0 and eth1 interfaces so that FreeSWITCH serves the calls from both eth1 and tun0 devices/networks, is it possible to instruct it to bind on different IP addresses (on tun0 and eth1 respectively) in order to serve calls to/from these networks? I do *not* wish to bind to 0.0.0.0 - just use the interfaces I am interested in - tun0 and eth1 in my case.
Yes, FreeSWITCH can bind to multiple interfaces. In FreeSWITCH lingo that would mean that you set up a separate SIP profile for each interface. (In fact, you can have more than one SIP profile on a given interface since the profile is a unique combo of IP addr and port number.)
If all of the above is possible, do I have to mess about and configure SNAT/DNAT separately and use sip kernel module "helpers" etc (I *do* have the routing set up properly though - that I am sure works 100%) or is FreeSWITCH perfectly capable of setting it all up for me?
"Some assembly required." :D FreeSWITCH can do some stuff for you, but you definitely need to make sure that your NAT is not behaving badly, like having a SIP ALG.
One final query: is there a decent distribution source package of FreeSWITCH, which I could take and then use it to build a binary package (I use Fedora on all of our machines). I need this, because all of our images are built using the rpm packaging system and I cannot just "fetch the latest git", compile and install FreeSWITCH - I need it packaged, so that the image builder picks it up and distributes it to the machine concerned. I checked the SUSE repository (as instructed on the FreeSWITCH wiki), but found 2 packages, both of which cannot be build due to errors!
I'll have to defer to Ken Rice on this one. I know he's working on RPMs for FreeSWITCH but I think it's all RedHat right now.
Many thanks in advance!
Welcome to FreeSWITCH! Pleasure.
But calls will be sent to FreeSWITCH by some device, correct? If it's good old-fashioned SIP then FreeSWITCH will handle it just fine. Yes, there are all softphones (PC machines with old-fashioned headset & mic and smartphones running a sip client).
Could this be done relatively easily in FreeSWITCH?
"Relatively?" Of course! It's relatively easy for someone with some experience. I highly recommend that you ask consulting@freeswitch.org <mailto:consulting@freeswitch.org> for professional assistance if you are not comfortable doing this all by yourself.
I'd rather do it by myself. For now though, I'd like to see whether what I want to achieve is possible in FreeSWITCH. I haven't yet made a decision what to use though - Asterisk or FreeSWITCH, it will all depend on whether I could set it up properly and "relatively" easy. Having said all that, as I developer with quite a bit of experience behind me, I am not afraid to delve in and get my hands dirty, if needed. I just want to make sure that what I want in terms of set up and functionality is possible.
Yes, FreeSWITCH can bind to multiple interfaces. In FreeSWITCH lingo that would mean that you set up a separate SIP profile for each interface. (In fact, you can have more than one SIP profile on a given interface since the profile is a unique combo of IP addr and port number.) I presume different profiles can "talk" to each other, right? In other words calls/media can be routed/transferred from one interface to another (eth1<->tun0 for example)?
"Some assembly required." :D FreeSWITCH can do some stuff for you, but you definitely need to make sure that your NAT is not behaving badly, like having a SIP ALG. This is what I am trying to figure out - do I rely entirely on FreeSWITCH (if not, what is expected of me to set up so that FreeSWITCH can do its job?), or do I have to do it all by myself with the kernel module helpers (sip, h323 etc) and ip/iptables?
I'll have to defer to Ken Rice on this one. I know he's working on RPMs for FreeSWITCH but I think it's all RedHat right now. RedHat is good, all I need is a decent .spec file - I'll do the rest myself, no problem.
One thing I seem to have forgotten from my newbie list of questions - I take it FreeSWITCH can do call-recording (in both directions) right? If so, how is this stored/implemented (I hope both ends are stored as a single sound file)? I would like all calls to be recorded as a matter of policy, so I do need this implemented if I am going to use FreeSWITCH. Many thanks again.
But calls will be sent to FreeSWITCH by some device, correct? If it's good old-fashioned SIP then FreeSWITCH will handle it just fine. Yes, there are all softphones (PC machines with old-fashioned headset & mic and smartphones running a sip client). Forgot to add - external calls (via the external VOIP provider) cannot be received via the FreeSWITCH listening port because of the fact that my ISP blocks connections initiated from outside. When a connection request (SYN) is initiated from my side, my ISP allows it, no problem (I believe the applicable term in such scenarios would be "fascist firewall").
What usually happens is that the control channel to my external VOIP provider on port 5060 is initiated by my end and when a call needs to be received from outside, this is communicated through the control channel (which is kept open at all times) and then my client opens both rtp data stream connections to receive the call. Does that make sense?
One thing I seem to have forgotten from my newbie list of questions - I take it FreeSWITCH can do call-recording (in both directions) right? If so, how is this stored/implemented (I hope both ends are stored as a single sound file)? I would like all calls to be recorded as a matter of policy, so I do need this implemented if I am going to use FreeSWITCH.
Yes, FS can record as long as it's in the media path. You can save as any format that FS can handle, including .mp3 if mod_shout is loaded - see http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_record_session It saves both channels to one file, but you have the option to record only caller/callee or to swap the channels. There doesn't seem to be a "flatten to mono" option. See the RECORD_* links at the bottom of that page. -Avi
Yes, FS can record as long as it's in the media path. You can save as any format that FS can handle, including .mp3 if mod_shout is loaded - see http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_record_session Thanks, that's a good find!
I also found solution to another common feature I was planning to add: call screening (screening of calls with unknown/missing CID or from numbers I don't know or have placed in a special group) - in Asterisk this is a bit limited to about 2, 3 options which I have no control over, but in FreeSWITCH, it seems, I have a complete freedom of how/what to do when call screening is initiated - http://wiki.freeswitch.org/wiki/Dialplan_XML (Example 13) is exactly what I needed, though I take it I could customise it a bit so that: I (as the called party) have the option (by pressing a specific key after receiving the caller's name) to: 1) accept the call; 2) send a message back to the caller saying this number is unavailable and then terminate his/her call; 3) redirect him/her to voicemail; 4) drop the call entirely without giving any explanation at all (or, alternatively, torture them with some moh if they appear to be telemarketing group for example). By reading that example, it looks as though this can be achieved. One other thing: in Asterisk, there is a vast sound library for various messages/music/media which could be used. Is there a similar thing in FreeSWITCH or should I use Asterisk's media pack for now?
It saves both channels to one file, but you have the option to record only caller/callee or to swap the channels. There doesn't seem to be a "flatten to mono" option. See the RECORD_* links at the bottom of that page. If I use <action application="set" data="RECORD_STEREO=false"/> would that be sufficient to record mono instead?
I also found solution to another common feature I was planning to add: call screening (screening of calls with unknown/missing CID or from numbers I don't know or have placed in a special group) - in Asterisk this is a bit limited to about 2, 3 options which I have no control over, but in FreeSWITCH, it seems, I have a complete freedom of how/what to do when call screening is initiated - http://wiki.freeswitch.org/wiki/Dialplan_XML (Example 13) is exactly what I needed, though I take it I could customise it a bit so that:
I (as the called party) have the option (by pressing a specific key after receiving the caller's name) to: 1) accept the call; 2) send a message back to the caller saying this number is unavailable and then terminate his/her call; 3) redirect him/her to voicemail; 4) drop the call entirely without giving any explanation at all (or, alternatively, torture them with some moh if they appear to be telemarketing group for example). By reading that example, it looks as though this can be achieved.
If you only need "answer or reject to continue with the dialplan" then
simply use the pre-built Answer Confirmation: http://wiki.freeswitch.org/wiki/Freeswitch_IVR_Originate#Answer_confirmation Anything else will be a bit more complicated. For telemarketers, you could bridge them to http://itslenny.com/
One other thing: in Asterisk, there is a vast sound library for various messages/music/media which could be used. Is there a similar thing in FreeSWITCH or should I use Asterisk's media pack for now?
When installing if you did "make sounds-install" you got the basic sound package which is quite extensive. I recommend looking at the docs/phrase/phrase_en.xml and see the list of the phrases / pre-recorded sound files under the name "callie". -Avi
I (as the called party) have the option (by pressing a specific key after receiving the caller's name) to: 1) accept the call; 2) send a message back to the caller saying this number is unavailable and then terminate his/her call; 3) redirect him/her to voicemail; 4) drop the call entirely without giving any explanation at all (or, alternatively, torture them with some moh if they appear to be telemarketing group for example). By reading that example, it looks as though this can be achieved.
If you only need "answer or reject to continue with the dialplan" then simply use the pre-built Answer Confirmation: http://wiki.freeswitch.org/wiki/Freeswitch_IVR_Originate#Answer_confirmation Anything else will be a bit more complicated.
According to the example I posted earlier (Example 13) it all seemed configurable as all of the steps taken were separate actions with parameters, which were completely configurable, so, naturally, I presumed that I could tweak this a bit to suit my own needs, isn't that so?
For telemarketers, you could bridge them to http://itslenny.com/ :-) Thanks, I'll keep that in mind!
When installing if you did "make sounds-install" you got the basic sound package which is quite extensive. I recommend looking at the docs/phrase/phrase_en.xml and see the list of the phrases / pre-recorded sound files under the name "callie". I will - thanks for the pointer. I haven't reached the "installation" stage yet - I am yet to decide whether to use FreeSWITCH, but will certainly look at the sound/media resources provided with it. Thanks again for your input.
If you're willing to get your hands dirty then that's great. I recommend the following resources: * Our "bridge" book - it covers a lot of the basics of FreeSWITCH. There are links to Amazon and Packt Publishing from our main wiki page * The forthcoming FreeSWITCH Cookbook. You can pre-order now. I'll throw some links up on the main page and wiki page, but if you go to PacktPub.com or Amazon.com just do a book search for FreeSWITCH and you'll find it. There's only two titles. :P * You're already on the mailing list, so karma++ for you * The IRC channel: #freeswitch on irc.freenode.net. This is, hands down, the best place to talk in real time about FreeSWITCH stuff * The wiki - it's got TONS of information. Yes, I'll admit you may have to dig and you may find confusing or contradictory information but we do our best to keep it updated. Just let us know if you find that something is wrong/confusing/missing on the wiki * The Wednesday conference calls - We do a weekly conference call for members of the community. You can interact with power users and occasionally even the developers themselves. We usually have a "feature presentation" after which we let folks do an open Q&A. As for the choice between Asterisk and FreeSWITCH: we respect your decision, and I promise we won't cry if you choose Asterisk or PIAF or whatever. However, many members of the FS community are "Asterisk refugees" who've been burned by mysterious deadlocks, segfaults, scaling issues, etc. If you ask us about our Asterisk experiences be prepared for horror stories. :D That being said, lots of people use Asterisk with no apparent issues. It's up to you. No matter which way you go, be prepared for aggravating problems and pulling your hair out. VoIP and telephony are always frustrating for the new user. Most of our community members remember their newbie pain and are quite willing to offer their knowledge and experience to help you keep at least some of your hair. ;) Let us know what you decide! -MC (IRC: mercutioviz) On Thu, Feb 9, 2012 at 6:09 AM, Josh <mojo1736@privatedemail.net> wrote:
Welcome to FreeSWITCH! Pleasure.
But calls will be sent to FreeSWITCH by some device, correct? If it's good old-fashioned SIP then FreeSWITCH will handle it just fine. Yes, there are all softphones (PC machines with old-fashioned headset & mic and smartphones running a sip client).
Could this be done relatively easily in FreeSWITCH?
"Relatively?" Of course! It's relatively easy for someone with some experience. I highly recommend that you ask consulting@freeswitch.org <mailto:consulting@freeswitch.org> for professional assistance if you are not comfortable doing this all by yourself.
I'd rather do it by myself. For now though, I'd like to see whether what I want to achieve is possible in FreeSWITCH. I haven't yet made a decision what to use though - Asterisk or FreeSWITCH, it will all depend on whether I could set it up properly and "relatively" easy. Having said all that, as I developer with quite a bit of experience behind me, I am not afraid to delve in and get my hands dirty, if needed. I just want to make sure that what I want in terms of set up and functionality is possible.
Yes, FreeSWITCH can bind to multiple interfaces. In FreeSWITCH lingo that would mean that you set up a separate SIP profile for each interface. (In fact, you can have more than one SIP profile on a given interface since the profile is a unique combo of IP addr and port number.) I presume different profiles can "talk" to each other, right? In other words calls/media can be routed/transferred from one interface to another (eth1<->tun0 for example)?
"Some assembly required." :D FreeSWITCH can do some stuff for you, but you definitely need to make sure that your NAT is not behaving badly, like having a SIP ALG. This is what I am trying to figure out - do I rely entirely on FreeSWITCH (if not, what is expected of me to set up so that FreeSWITCH can do its job?), or do I have to do it all by myself with the kernel module helpers (sip, h323 etc) and ip/iptables?
I'll have to defer to Ken Rice on this one. I know he's working on RPMs for FreeSWITCH but I think it's all RedHat right now. RedHat is good, all I need is a decent .spec file - I'll do the rest myself, no problem.
One thing I seem to have forgotten from my newbie list of questions - I take it FreeSWITCH can do call-recording (in both directions) right? If so, how is this stored/implemented (I hope both ends are stored as a single sound file)? I would like all calls to be recorded as a matter of policy, so I do need this implemented if I am going to use FreeSWITCH.
Many thanks again.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
If you're willing to get your hands dirty then that's great. I recommend the following resources: All noted, except irc - not really an option for me at the moment. Thanks!
No matter which way you go, be prepared for aggravating problems and pulling your hair out. VoIP and telephony are always frustrating for the new user. Most of our community members remember their newbie pain and are quite willing to offer their knowledge and experience to help you keep at least some of your hair. ;) Hope so - the main reason I joined this ML.
Let us know what you decide! I haven't made a decision yet one way or another - "the devil is in the detail" as they say.
I would like to identify potential "issues" or "stumbling blocks" as early as possible, so that I don't regret it later on (and start pulling my hair out :-) ) when I truly delve in - I do not wish to spend long hours researching, as well as part with my hard-earned, just to find out midway through that something I'd like to do won't be possible for one reason or another. That would be a complete waste, literally. It would be nice if someone could address my questions, if possible (highlighted again below - with one or two additions ;-) ) - some of these issues I know are not as straight forward in Asterisk, so I'd like to find out how these are solved/implemented in FreeSWITCH?
> Yes, FreeSWITCH can bind to multiple interfaces. In FreeSWITCH lingo > that would mean that you set up a separate SIP profile for each > interface. (In fact, you can have more than one SIP profile on a given > interface since the profile is a unique combo of IP addr and port number.) I presume different profiles can "talk" to each other, right? In other words calls/media can be routed/transferred from one interface to another (eth1<->tun0 for example)?
Is this relatively straight-forward to configure?
> "Some assembly required." :D > FreeSWITCH can do some stuff for you, but you definitely need to make > sure that your NAT is not behaving badly, like having a SIP ALG. This is what I am trying to figure out - do I rely entirely on FreeSWITCH (if not, what is expected of me to set up so that FreeSWITCH can do its job?), or do I have to do it all by myself with the kernel module helpers (sip, h323 etc) and ip/iptables?
The reason I asked this, is simply because I need to know whether I am required to set it all up (nothing wrong with that, just that I don't want to be put in a position where I stumble across a problem and don't know who is to blame - my sip helper module, iptables, or FreeSWITCH itself) or do I leave it all to FreeSWITCH. Another issue which I did not mention up until now - I *assume* FreeSWITCH operates in a similar way as Asterisk does with regards to separation of channels/streams - in other words, if someone calls via the "public" interface/my external VOIP provider, then FreeSWITCH goes through the configured dialplan and then opens up a separate channel (on the internal interface) to ring and connect the call and then "bridges" the two streams/channels together. Is that the case? If so, would it be possible to have different levels of encryption/security set on the two channels - say TLS/SRTP on the public part and no encryption on the internal system? Would that be possible or do I have to have the same settings on all interfaces so that FreeSWITCH could handle it properly?
> I'll have to defer to Ken Rice on this one. I know he's working on > RPMs for FreeSWITCH but I think it's all RedHat right now. RedHat is good, all I need is a decent .spec file - I'll do the rest myself, no problem.
That, really, is important to me as this is how I'd like to start and experiment. Once I have the .spec file I would be able to package it and distribute it across a couple of testing machine I have here so that I could experiment a bit. The distro this .spec file comes from doesn't matter too much - whether it is Fedora/RedHat, SUSE, etc I would be able to change the .spec file and adapt it to my system - I have done this many times before, so it won't be too much of a problem for me, I think, provided the .spec file is decent. Many thanks yet again!
participants (3)
-
Avi Marcus
-
Josh
-
Michael Collins