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!