Personally, I patched the default conf, one step at a time. The good thing with that is that it forces you to understand most parameters, which is always good thing (who would want to fly a plane, not knowing what use is the little yellow button, just there). In a specific file, if you are not sure about a parameter, just remove it, and see if your app still works, but most default parameters do no harm. For modules, the safe path is to disable all the useless ones, so you don't really care about the default conf. David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur. Le 05/07/2011 à 03:39, Bryan Smart a écrit :
Does it still include conf files for the modules, but with all possible disabled?
For those of you with large deployed voice apps or switches, what do you do? Do you blow away the conf dir and totally start from scratch?
Bryan
On Jul 4, 2011, at 9:29 PM, Michael Collins wrote:
I think the best "skeleton" config is Brian West's soft-phone configuration. It looks like we haven't migrated the download link over to git yet so I will see if I can't track it down. In the meantime if anyone has a copy of that config please post it here.
What's nice about it is that it's basically just one file with an option to read in gateway configs from a subdirectory. It's only a few hundred lines of XML and it shows what you can do with just a single config file.
-MC
On Mon, Jul 4, 2011 at 4:56 PM, Bryan Smart <bryansmart@bryansmart.com> wrote: Is a truly skeletal configuration available? As far as I can tell, the choice right now is to start with no configuration files at all, or else to install a sample set that is bursting with stuff.
So far, I've installed the samples, and tried to strip out the parts that are obviously not needed by me:
The dialplan is the best example that I can think of: all the exts that replace functions on Snom/Linksys phones, record/play video, demo substitute ring tone, call groups, add/del groups, dynamically create numerous types of conferences, call features like redial/hold/etc, the exts for the demo IVR, and so on. I know enough to know that I don't want those on a live system, but I don't know enough to know if it is safe to remove parts. Will I break refer or deflect if I get rid of the "refer" ext? Is "unloop" only necessary as a safety feature if I'm connecting sessions to SIP URIs outside of the local FS? ? Can I drop "external-sip-uri" if users won't be calling external URIs, or will that completely block FS from connecting to external URIs in all cases? I think I can dump features.xml altogether.
There are an internal and external SIP profile. If I'm only hosting a voice application, I think I can dump the internal profile and just run the default external profile on 5060, but there are a huge amount of options in there that look as if they're setup to cover cases where the external profile is used to connect to ITSPs, which I won't.
There are so many configuration files that I'm not comfortable with blowing the whole directory tree away and recreating a raw basics version of each of them. While I don't feel paranoid about a specific part of the security of the full samples install, my rule is always that I try to not run anything that I don't at least somewhat understand. There seem to be so many little demos and optional features that I know that I by no means understand the implications of what they could be used to do in combination with what I'll add later. It seems safer to start from the bare basics, and only add what is needed, but, for now, I must start with the samples, and try to strip away as much as I can without breaking FS.
For me, I'm using FS as a platform for running a voice app, so I need little, if any, PBX type features. Some people that might wish to use FS as a PBX might not want all of the demo bits, though. An absolute minimum set of configuration files, as well as a set containing the essentials for a app platform or PBX would be useful, if they don't already exist somewhere.
Bryan
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
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
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
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
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
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