Thoughts on security/code injection/etc. in FS when allowing user supplied data
I've noticed several places in FS code and examples where it isn't safe at all to take user supplied data. An easy example is the use of mailer_app: #ifdef WIN32 switch_snprintf(buf, B64BUFFLEN, "\"\"%s\" -f %s %s %s < \"%s\"\"", runtime.mailer_app, from, runtime.mailer_app_args, to, filename); #else switch_snprintf(buf, B64BUFFLEN, "/bin/cat %s | %s -f %s %s %s", filename, runtime.mailer_app, from, runtime.mailer_app_args, to); #endif another is ANY use of passing channel vars or data to a system or bgsystem command. This isn't an issue normally, but if you want to give limited ability for users to control their own dial rules, then you wind up having to be very careful with processing the data to make sure it's safe. That's always a good idea, but it still seems like a bad idea to take that data and then directly use it in a completely unsafe context like a parsed command line. For the voicemail notify case, seems like an easy answer would be something like a "vm-notify-hook", which at that point, could call out to lua or perl to do the actual sending in a safe manner, passing the recipient/sender/etc. as data instead of on cmd line. For the 'passing channel vars...' case, I think it would be good to have a 'system_json' and 'bgsystem_json' set of routines that would pass channel data to the script on stdin in json format. Regardless of implementation of either of those, I think it would be worthwhile to have a shell_escape() routine in the core utilities to allow the current syntax to be used more safely. -- Nathan ------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
I am glad to see someone is concerned about input validation when it comes to voip. It is much neglected when we're constructing our services, partly due to the fact that it's still considered black magic. I believe that system and bgsystem should be strictly regulated and ani and sip vars should be safe-parsed before feeding to a turing machine. Security through obscurity has never worked and i beth my both legs we all have a few vulnerable applications behind our backs. Let's unite to make FS the most stable and secure softswitch out there. On May 19, 2013 5:21 PM, "Nathan Neulinger" <nneul@mst.edu> wrote:
I've noticed several places in FS code and examples where it isn't safe at all to take user supplied data.
An easy example is the use of mailer_app:
#ifdef WIN32 switch_snprintf(buf, B64BUFFLEN, "\"\"%s\" -f %s %s %s < \"%s\"\"", runtime.mailer_app, from, runtime.mailer_app_args, to, filename); #else switch_snprintf(buf, B64BUFFLEN, "/bin/cat %s | %s -f %s %s %s", filename, runtime.mailer_app, from, runtime.mailer_app_args, to); #endif
another is ANY use of passing channel vars or data to a system or bgsystem command.
This isn't an issue normally, but if you want to give limited ability for users to control their own dial rules, then you wind up having to be very careful with processing the data to make sure it's safe. That's always a good idea, but it still seems like a bad idea to take that data and then directly use it in a completely unsafe context like a parsed command line.
For the voicemail notify case, seems like an easy answer would be something like a "vm-notify-hook", which at that point, could call out to lua or perl to do the actual sending in a safe manner, passing the recipient/sender/etc. as data instead of on cmd line.
For the 'passing channel vars...' case, I think it would be good to have a 'system_json' and 'bgsystem_json' set of routines that would pass channel data to the script on stdin in json format.
Regardless of implementation of either of those, I think it would be worthwhile to have a shell_escape() routine in the core utilities to allow the current syntax to be used more safely.
-- Nathan
------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
_________________________________________________________________________ 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
This could really use some input from Tony, as it really comes down to a design decision. It could be argued that you should not be exposing raw configuration to your customers without sanitizing the input yourselves.. and it could be argued that the input should be sanitized anyway. FS isn't attempting to push security through obscurity (given that all the code is open source), but many closed source products do. Either way, it would be good to hear Tony's thoughts on this. Cal On Sun, May 19, 2013 at 8:21 PM, Daniel Ivanov <sertys@gmail.com> wrote:
I am glad to see someone is concerned about input validation when it comes to voip. It is much neglected when we're constructing our services, partly due to the fact that it's still considered black magic. I believe that system and bgsystem should be strictly regulated and ani and sip vars should be safe-parsed before feeding to a turing machine. Security through obscurity has never worked and i beth my both legs we all have a few vulnerable applications behind our backs. Let's unite to make FS the most stable and secure softswitch out there. On May 19, 2013 5:21 PM, "Nathan Neulinger" <nneul@mst.edu> wrote:
I've noticed several places in FS code and examples where it isn't safe at all to take user supplied data.
An easy example is the use of mailer_app:
#ifdef WIN32 switch_snprintf(buf, B64BUFFLEN, "\"\"%s\" -f %s %s %s < \"%s\"\"", runtime.mailer_app, from, runtime.mailer_app_args, to, filename); #else switch_snprintf(buf, B64BUFFLEN, "/bin/cat %s | %s -f %s %s %s", filename, runtime.mailer_app, from, runtime.mailer_app_args, to); #endif
another is ANY use of passing channel vars or data to a system or bgsystem command.
This isn't an issue normally, but if you want to give limited ability for users to control their own dial rules, then you wind up having to be very careful with processing the data to make sure it's safe. That's always a good idea, but it still seems like a bad idea to take that data and then directly use it in a completely unsafe context like a parsed command line.
For the voicemail notify case, seems like an easy answer would be something like a "vm-notify-hook", which at that point, could call out to lua or perl to do the actual sending in a safe manner, passing the recipient/sender/etc. as data instead of on cmd line.
For the 'passing channel vars...' case, I think it would be good to have a 'system_json' and 'bgsystem_json' set of routines that would pass channel data to the script on stdin in json format.
Regardless of implementation of either of those, I think it would be worthwhile to have a shell_escape() routine in the core utilities to allow the current syntax to be used more safely.
-- Nathan
------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
_________________________________________________________________________ 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
_________________________________________________________________________ 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
Agreed. I was actually (in my case) less concerned about security than 'oops that didn't do the right thing' for stuff as simple as "user email address(es)" - accidentally using a ";" to separate them (users coming from outlook for example) would result in a completely improper behavior - trying to run user address as a command... Similar for something like "send this caller-id name to this external system command" - too many places where a seemingly legitimate use is really insecure. I submitted a Jira with a patch to at least add a shell quoting function, and another one to make use of that shell quoting for the email addr in switch_simple_email. I'm sure there are others, but I wanted to cover a couple obvious cases. Would need more work to be fully useful though... -- Nathan On 05/19/2013 02:50 PM, Cal Leeming [Simplicity Media Ltd] wrote:
This could really use some input from Tony, as it really comes down to a design decision.
It could be argued that you should not be exposing raw configuration to your customers without sanitizing the input yourselves.. and it could be argued that the input should be sanitized anyway.
FS isn't attempting to push security through obscurity (given that all the code is open source), but many closed source products do.
Either way, it would be good to hear Tony's thoughts on this.
Cal
On Sun, May 19, 2013 at 8:21 PM, Daniel Ivanov <sertys@gmail.com <mailto:sertys@gmail.com>> wrote:
I am glad to see someone is concerned about input validation when it comes to voip. It is much neglected when we're constructing our services, partly due to the fact that it's still considered black magic. I believe that system and bgsystem should be strictly regulated and ani and sip vars should be safe-parsed before feeding to a turing machine. Security through obscurity has never worked and i beth my both legs we all have a few vulnerable applications behind our backs. Let's unite to make FS the most stable and secure softswitch out there.
On May 19, 2013 5:21 PM, "Nathan Neulinger" <nneul@mst.edu <mailto:nneul@mst.edu>> wrote:
I've noticed several places in FS code and examples where it isn't safe at all to take user supplied data.
An easy example is the use of mailer_app:
#ifdef WIN32 switch_snprintf(buf, B64BUFFLEN, "\"\"%s\" -f %s %s %s < \"%s\"\"", runtime.mailer_app, from, runtime.mailer_app_args, to, filename); #else switch_snprintf(buf, B64BUFFLEN, "/bin/cat %s | %s -f %s %s %s", filename, runtime.mailer_app, from, runtime.mailer_app_args, to); #endif
another is ANY use of passing channel vars or data to a system or bgsystem command.
This isn't an issue normally, but if you want to give limited ability for users to control their own dial rules, then you wind up having to be very careful with processing the data to make sure it's safe. That's always a good idea, but it still seems like a bad idea to take that data and then directly use it in a completely unsafe context like a parsed command line.
For the voicemail notify case, seems like an easy answer would be something like a "vm-notify-hook", which at that point, could call out to lua or perl to do the actual sending in a safe manner, passing the recipient/sender/etc. as data instead of on cmd line.
For the 'passing channel vars...' case, I think it would be good to have a 'system_json' and 'bgsystem_json' set of routines that would pass channel data to the script on stdin in json format.
Regardless of implementation of either of those, I think it would be worthwhile to have a shell_escape() routine in the core utilities to allow the current syntax to be used more safely.
-- Nathan
------------------------------------------------------------ Nathan Neulinger nneul@mst.edu <mailto:nneul@mst.edu> Missouri S&T Information Technology (573) 612-1412 <tel:%28573%29%20612-1412> System Administrator - Architect
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto: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 <mailto: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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto: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 <mailto: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
-- ------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
All of FS gives you unrestricted access -- raw XML, mod_xml_curl, lua, etc. If you want to limit access, use http://wiki.freeswitch.org/wiki/Mod_httapi -- it has a permissions option for what the user is allowed to access. THAT system has a permission framework. If you find a bug in there, then there's something to do about it. -Avi On Sun, May 19, 2013 at 11:26 PM, Nathan Neulinger <nneul@mst.edu> wrote:
Agreed. I was actually (in my case) less concerned about security than 'oops that didn't do the right thing' for stuff as simple as "user email address(es)" - accidentally using a ";" to separate them (users coming from outlook for example) would result in a completely improper behavior - trying to run user address as a command...
Similar for something like "send this caller-id name to this external system command" - too many places where a seemingly legitimate use is really insecure.
I submitted a Jira with a patch to at least add a shell quoting function, and another one to make use of that shell quoting for the email addr in switch_simple_email. I'm sure there are others, but I wanted to cover a couple obvious cases.
Would need more work to be fully useful though...
-- Nathan
On 05/19/2013 02:50 PM, Cal Leeming [Simplicity Media Ltd] wrote:
This could really use some input from Tony, as it really comes down to a design decision.
It could be argued that you should not be exposing raw configuration to your customers without sanitizing the input yourselves.. and it could be argued that the input should be sanitized anyway.
FS isn't attempting to push security through obscurity (given that all the code is open source), but many closed source products do.
Either way, it would be good to hear Tony's thoughts on this.
Cal
On Sun, May 19, 2013 at 8:21 PM, Daniel Ivanov <sertys@gmail.com<mailto: sertys@gmail.com>> wrote:
I am glad to see someone is concerned about input validation when it comes to voip. It is much neglected when we're constructing our services, partly due to the fact that it's still considered black magic. I believe that system and bgsystem should be strictly regulated and ani and sip vars should be safe-parsed before feeding to a turing machine. Security through obscurity has never worked and i beth my both legs we all have a few vulnerable applications behind our backs. Let's unite to make FS the most stable and secure softswitch out there.
On May 19, 2013 5:21 PM, "Nathan Neulinger" <nneul@mst.edu <mailto: nneul@mst.edu>> wrote:
I've noticed several places in FS code and examples where it isn't safe at all to take user supplied data.
An easy example is the use of mailer_app:
#ifdef WIN32 switch_snprintf(buf, B64BUFFLEN, "\"\"%s\" -f %s %s %s < \"%s\"\"", runtime.mailer_app, from, runtime.mailer_app_args, to, filename); #else switch_snprintf(buf, B64BUFFLEN, "/bin/cat %s | %s -f %s %s %s", filename, runtime.mailer_app, from, runtime.mailer_app_args, to); #endif
another is ANY use of passing channel vars or data to a system or bgsystem command.
This isn't an issue normally, but if you want to give limited ability for users to control their own dial rules, then you wind up having to be very careful with processing the data to make sure it's safe. That's always a good idea, but it still seems like a bad idea to take that data and then directly use it in a completely unsafe context like a parsed command line.
For the voicemail notify case, seems like an easy answer would be something like a "vm-notify-hook", which at that point, could call out to lua or perl to do the actual sending in a safe manner, passing the recipient/sender/etc. as data instead of on cmd line.
For the 'passing channel vars...' case, I think it would be good to have a 'system_json' and 'bgsystem_json' set of routines that would pass channel data to the script on stdin in json format.
Regardless of implementation of either of those, I think it would be worthwhile to have a shell_escape() routine in the core utilities to allow the current syntax to be used more safely.
-- Nathan
------------------------------------------------------------ Nathan Neulinger nneul@mst.edu <mailto:nneul@mst.edu> Missouri S&T Information Technology (573) 612-1412<tel:%28573%29%20612-1412> System Administrator - Architect
_________________________________________________________________________
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto: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 <mailto:
FreeSWITCH-users@lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
_________________________________________________________________________
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto: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 <mailto:
FreeSWITCH-users@lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
-- ------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
_________________________________________________________________________ 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
I'm not giving users direct access to the system/APIs/etc - it's just via a portal/UI - but there's a difference between "worry about user screwing up their dialplan from me missing something if I let them define an email address" vs "give user full unrestricted access cause the use of email address in the core doesn't even quote command line arguments". In both cases, I still need to be concerned with sanitizing input - more a matter of what the defense-in-depth looks like. Right now - if I _want_ to allow untrusted input in certain circumstances - such as passing caller id info to an external executable, there simply is no way to do it safely. That's what the patches are for. -- Nathan On 05/19/2013 04:06 PM, Avi Marcus wrote:
All of FS gives you unrestricted access -- raw XML, mod_xml_curl, lua, etc.
If you want to limit access, use http://wiki.freeswitch.org/wiki/Mod_httapi -- it has a permissions option for what the user is allowed to access. THAT system has a permission framework. If you find a bug in there, then there's something to do about it. -Avi
On Sun, May 19, 2013 at 11:26 PM, Nathan Neulinger <nneul@mst.edu <mailto:nneul@mst.edu>> wrote:
Agreed. I was actually (in my case) less concerned about security than 'oops that didn't do the right thing' for stuff as simple as "user email address(es)" - accidentally using a ";" to separate them (users coming from outlook for example) would result in a completely improper behavior - trying to run user address as a command...
Similar for something like "send this caller-id name to this external system command" - too many places where a seemingly legitimate use is really insecure.
I submitted a Jira with a patch to at least add a shell quoting function, and another one to make use of that shell quoting for the email addr in switch_simple_email. I'm sure there are others, but I wanted to cover a couple obvious cases.
Would need more work to be fully useful though...
-- Nathan
On 05/19/2013 02:50 PM, Cal Leeming [Simplicity Media Ltd] wrote: > This could really use some input from Tony, as it really comes down to a design decision. > > It could be argued that you should not be exposing raw configuration to your customers without sanitizing the input > yourselves.. and it could be argued that the input should be sanitized anyway. > > FS isn't attempting to push security through obscurity (given that all the code is open source), but many closed source > products do. > > Either way, it would be good to hear Tony's thoughts on this. > > Cal > > On Sun, May 19, 2013 at 8:21 PM, Daniel Ivanov <sertys@gmail.com <mailto:sertys@gmail.com> <mailto:sertys@gmail.com <mailto:sertys@gmail.com>>> wrote: > > I am glad to see someone is concerned about input validation when it comes to voip. It is much neglected when we're > constructing our services, partly due to the fact that it's still considered black magic. I believe that system and > bgsystem should be strictly regulated and ani and sip vars should be safe-parsed before feeding to a turing > machine. Security through obscurity has never worked and i beth my both legs we all have a few vulnerable > applications behind our backs. Let's unite to make FS the most stable and secure softswitch out there. > > On May 19, 2013 5:21 PM, "Nathan Neulinger" <nneul@mst.edu <mailto:nneul@mst.edu> <mailto:nneul@mst.edu <mailto:nneul@mst.edu>>> wrote: > > I've noticed several places in FS code and examples where it isn't safe at all to take user supplied data. > > An easy example is the use of mailer_app: > > > #ifdef WIN32 > switch_snprintf(buf, B64BUFFLEN, "\"\"%s\" -f %s %s %s < \"%s\"\"", runtime.mailer_app, from, > runtime.mailer_app_args, to, filename); > #else > switch_snprintf(buf, B64BUFFLEN, "/bin/cat %s | %s -f %s %s %s", filename, runtime.mailer_app, from, > runtime.mailer_app_args, to); > #endif > > another is ANY use of passing channel vars or data to a system or bgsystem command. > > > This isn't an issue normally, but if you want to give limited ability for users to control their own dial rules, > then > you wind up having to be very careful with processing the data to make sure it's safe. That's always a good > idea, but it > still seems like a bad idea to take that data and then directly use it in a completely unsafe context like a parsed > command line. > > For the voicemail notify case, seems like an easy answer would be something like a "vm-notify-hook", which at that > point, could call out to lua or perl to do the actual sending in a safe manner, passing the recipient/sender/etc. as > data instead of on cmd line. > > For the 'passing channel vars...' case, I think it would be good to have a 'system_json' and 'bgsystem_json' set of > routines that would pass channel data to the script on stdin in json format. > > Regardless of implementation of either of those, I think it would be worthwhile to have a shell_escape() routine > in the > core utilities to allow the current syntax to be used more safely. > > -- Nathan > > ------------------------------------------------------------ > Nathan Neulinger nneul@mst.edu <mailto:nneul@mst.edu> <mailto:nneul@mst.edu <mailto:nneul@mst.edu>> > Missouri S&T Information Technology (573) 612-1412 <tel:%28573%29%20612-1412> <tel:%28573%29%20612-1412> > System Administrator - Architect > > _________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting@freeswitch.org <mailto:consulting@freeswitch.org> <mailto:consulting@freeswitch.org <mailto: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 <mailto:FreeSWITCH-users@lists.freeswitch.org> <mailto:FreeSWITCH-users@lists.freeswitch.org <mailto: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 > > > _________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting@freeswitch.org <mailto:consulting@freeswitch.org> <mailto:consulting@freeswitch.org <mailto: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 <mailto:FreeSWITCH-users@lists.freeswitch.org> <mailto:FreeSWITCH-users@lists.freeswitch.org <mailto: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 > >
-- ------------------------------------------------------------ Nathan Neulinger nneul@mst.edu <mailto:nneul@mst.edu> Missouri S&T Information Technology (573) 612-1412 <tel:%28573%29%20612-1412> System Administrator - Architect
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto: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 <mailto: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
-- ------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
participants (4)
-
Avi Marcus
-
Cal Leeming [Simplicity Media Ltd]
-
Daniel Ivanov
-
Nathan Neulinger