Hi. I've been developing a script for someone to handle credit card transactions via IVR. Is there a way to just set the particular channel/call to fsctl loglevel 6, rather than the entire switch..? (dtmf is shown in /log 7) And.. similarly is there a way to blank out the var digits_dialed in the xml_cdr, from within FS, before the end of the call? Thanks! -Avi
On Wed, May 30, 2012 at 4:30 AM, Avi Marcus <avi@avimarcus.net> wrote:
Hi. I've been developing a script for someone to handle credit card transactions via IVR. Is there a way to just set the particular channel/call to fsctl loglevel 6, rather than the entire switch..? (dtmf is shown in /log 7)
http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_session_loglevel
And.. similarly is there a way to blank out the var digits_dialed in the xml_cdr, from within FS, before the end of the call?
Why do you need to clear it out? What information does it collect that you don't need? -MC
On 30-05-12 17:48, Michael Collins wrote:
And.. similarly is there a way to blank out the var digits_dialed in the xml_cdr, from within FS, before the end of the call?
Why do you need to clear it out? What information does it collect that you don't need?
Since it's credit card data I can imagine Avi does not want it logged for security purposes. Regards, Patrick
If it's a compliance issue then I'd triple-check to make sure that no one unauthorized can get to any of your FS logs or CDR data. I suspect that logging vs. not logging dialed_digits is not a make-or-break proposition. If you're doing xml_cdrs then you've probably got that same data in other log lines. -MC On Wed, May 30, 2012 at 9:08 AM, Patrick Lists < freeswitch-list@puzzled.xs4all.nl> wrote:
On 30-05-12 17:48, Michael Collins wrote:
And.. similarly is there a way to blank out the var digits_dialed in the xml_cdr, from within FS, before the end of the call?
Why do you need to clear it out? What information does it collect that you don't need?
Since it's credit card data I can imagine Avi does not want it logged for security purposes.
Regards, Patrick
The PCI-DSS (Payment Card Industry Data Security Standard) requires encryption, not merely permission restriction, for sensitive data. Hence I'm looking at the DTMF logging which can probably be easily re-patterned back into the digits, the curl POST which also shows everything in the log, the dialed_digits in a standard xml_cdr.. Otherwise, afaik, lua won't log things unless you explicitly tell it to. Any suggestions other than setting the entire switch to fsctl loglevel 6 and not storing the xml_cdrs in their raw form? -Avi On Wed, May 30, 2012 at 8:11 PM, Michael Collins <msc@freeswitch.org> wrote:
If it's a compliance issue then I'd triple-check to make sure that no one unauthorized can get to any of your FS logs or CDR data. I suspect that logging vs. not logging dialed_digits is not a make-or-break proposition. If you're doing xml_cdrs then you've probably got that same data in other log lines.
-MC
On Wed, May 30, 2012 at 9:08 AM, Patrick Lists < freeswitch-list@puzzled.xs4all.nl> wrote:
On 30-05-12 17:48, Michael Collins wrote:
And.. similarly is there a way to blank out the var digits_dialed in the xml_cdr, from within FS, before the end of the call?
Why do you need to clear it out? What information does it collect that you don't need?
Since it's credit card data I can imagine Avi does not want it logged for security purposes.
Regards, Patrick
_________________________________________________________________________ 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
Join Us At ClueCon - Aug 7-9, 2012
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
How are you protecting everything else? If the XML CDR is sent over HTTP instead of HTTPS then everything about the call is plain text. And what about the FS logs? Are you encrypting those somehow? It seems to me that you need a more comprehensive solution than just scrubbing a single channel variable. However, if you need an interim solution I would suggest commenting out the line that sets digits_dialed: http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_channel.c?r=H... A more permanent solution might be to create a channel variable that controls whether stuff like this gets logged. Something like "no_dtmf_logging=true" or whatever. That's a bit more involved because you have to decide if there are other places where DTMF info gets logged and if so, decide whether or not you want not to log them. What would be the ideal solution for your scenario? That answer might yield the best course of action. -MC On Wed, May 30, 2012 at 11:20 AM, Avi Marcus <avi@avimarcus.net> wrote:
The PCI-DSS (Payment Card Industry Data Security Standard) requires encryption, not merely permission restriction, for sensitive data. Hence I'm looking at the DTMF logging which can probably be easily re-patterned back into the digits, the curl POST which also shows everything in the log, the dialed_digits in a standard xml_cdr.. Otherwise, afaik, lua won't log things unless you explicitly tell it to.
Any suggestions other than setting the entire switch to fsctl loglevel 6 and not storing the xml_cdrs in their raw form?
-Avi
On Wed, May 30, 2012 at 8:11 PM, Michael Collins <msc@freeswitch.org>wrote:
If it's a compliance issue then I'd triple-check to make sure that no one unauthorized can get to any of your FS logs or CDR data. I suspect that logging vs. not logging dialed_digits is not a make-or-break proposition. If you're doing xml_cdrs then you've probably got that same data in other log lines.
-MC
On Wed, May 30, 2012 at 9:08 AM, Patrick Lists < freeswitch-list@puzzled.xs4all.nl> wrote:
On 30-05-12 17:48, Michael Collins wrote:
And.. similarly is there a way to blank out the var digits_dialed
in
the xml_cdr, from within FS, before the end of the call?
Why do you need to clear it out? What information does it collect that you don't need?
Since it's credit card data I can imagine Avi does not want it logged for security purposes.
Regards, Patrick
_________________________________________________________________________ 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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
On Wed, May 30, 2012 at 11:18 PM, Michael Collins <msc@freeswitch.org>wrote:
How are you protecting everything else? If the XML CDR is sent over HTTP instead of HTTPS then everything about the call is plain text.
As far as I know, the only thing sensitive in the xml_cdr is digits_dialed.
And what about the FS logs? Are you encrypting those somehow? It seems to me that you need a more comprehensive solution than just scrubbing a single channel variable.
No, I'm not encrypting them.. because t here wouldn't be anything sensitive. As far as I can tell, the only issue is the DTMF in DEBUG and the curl post message, again in DEBUG. Since this is a lua IVR it seems nearly nothing else makes it into the log. Only api:execute("curl",...) is in the log because it's not a native direct curl command (like session:playandgetdigits())
However, if you need an interim solution I would suggest commenting out the line that sets digits_dialed:
http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_channel.c?r=H...
A more permanent solution might be to create a channel variable that controls whether stuff like this gets logged. Something like "no_dtmf_logging=true" or whatever. That's a bit more involved because you have to decide if there are other places where DTMF info gets logged and if so, decide whether or not you want not to log them.
That's an interesting idea... it might be more encompassing to have a loglevel=X channel variable instead that affects the logging for that channel. But this is probably overkill...
What would be the ideal solution for your scenario? That answer might yield the best course of action. -MC
On Wed, May 30, 2012 at 11:20 AM, Avi Marcus <avi@avimarcus.net> wrote:
The PCI-DSS (Payment Card Industry Data Security Standard) requires encryption, not merely permission restriction, for sensitive data. Hence I'm looking at the DTMF logging which can probably be easily re-patterned back into the digits, the curl POST which also shows everything in the log, the dialed_digits in a standard xml_cdr.. Otherwise, afaik, lua won't log things unless you explicitly tell it to.
Any suggestions other than setting the entire switch to fsctl loglevel 6 and not storing the xml_cdrs in their raw form?
-Avi
On Wed, May 30, 2012 at 8:11 PM, Michael Collins <msc@freeswitch.org>wrote:
If it's a compliance issue then I'd triple-check to make sure that no one unauthorized can get to any of your FS logs or CDR data. I suspect that logging vs. not logging dialed_digits is not a make-or-break proposition. If you're doing xml_cdrs then you've probably got that same data in other log lines.
-MC
On Wed, May 30, 2012 at 9:08 AM, Patrick Lists < freeswitch-list@puzzled.xs4all.nl> wrote:
On 30-05-12 17:48, Michael Collins wrote:
And.. similarly is there a way to blank out the var digits_dialed
in
the xml_cdr, from within FS, before the end of the call?
Why do you need to clear it out? What information does it collect that you don't need?
Since it's credit card data I can imagine Avi does not want it logged for security purposes.
Regards, Patrick
_________________________________________________________________________ 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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Avi, Can you think of any other places where the FS logging in general might contain sensitive data? Reason I ask is that maybe we could create something like "pcidss=true" and then use that as a flag to disable logging anything that might be considered sensitive. Just a thought. -MC On Wed, May 30, 2012 at 1:29 PM, Avi Marcus <avi@avimarcus.net> wrote:
On Wed, May 30, 2012 at 11:18 PM, Michael Collins <msc@freeswitch.org>wrote:
How are you protecting everything else? If the XML CDR is sent over HTTP instead of HTTPS then everything about the call is plain text.
As far as I know, the only thing sensitive in the xml_cdr is digits_dialed.
And what about the FS logs? Are you encrypting those somehow? It seems to me that you need a more comprehensive solution than just scrubbing a single channel variable.
No, I'm not encrypting them.. because t here wouldn't be anything sensitive. As far as I can tell, the only issue is the DTMF in DEBUG and the curl post message, again in DEBUG. Since this is a lua IVR it seems nearly nothing else makes it into the log. Only api:execute("curl",...) is in the log because it's not a native direct curl command (like session:playandgetdigits())
However, if you need an interim solution I would suggest commenting out the line that sets digits_dialed:
http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_channel.c?r=H...
A more permanent solution might be to create a channel variable that controls whether stuff like this gets logged. Something like "no_dtmf_logging=true" or whatever. That's a bit more involved because you have to decide if there are other places where DTMF info gets logged and if so, decide whether or not you want not to log them.
That's an interesting idea... it might be more encompassing to have a loglevel=X channel variable instead that affects the logging for that channel. But this is probably overkill...
What would be the ideal solution for your scenario? That answer might yield the best course of action. -MC
On Wed, May 30, 2012 at 11:20 AM, Avi Marcus <avi@avimarcus.net> wrote:
The PCI-DSS (Payment Card Industry Data Security Standard) requires encryption, not merely permission restriction, for sensitive data. Hence I'm looking at the DTMF logging which can probably be easily re-patterned back into the digits, the curl POST which also shows everything in the log, the dialed_digits in a standard xml_cdr.. Otherwise, afaik, lua won't log things unless you explicitly tell it to.
Any suggestions other than setting the entire switch to fsctl loglevel 6 and not storing the xml_cdrs in their raw form?
-Avi
On Wed, May 30, 2012 at 8:11 PM, Michael Collins <msc@freeswitch.org>wrote:
If it's a compliance issue then I'd triple-check to make sure that no one unauthorized can get to any of your FS logs or CDR data. I suspect that logging vs. not logging dialed_digits is not a make-or-break proposition. If you're doing xml_cdrs then you've probably got that same data in other log lines.
-MC
On Wed, May 30, 2012 at 9:08 AM, Patrick Lists < freeswitch-list@puzzled.xs4all.nl> wrote:
On 30-05-12 17:48, Michael Collins wrote:
And.. similarly is there a way to blank out the var
digits_dialed in
the xml_cdr, from within FS, before the end of the call?
Why do you need to clear it out? What information does it collect
that
you don't need?
Since it's credit card data I can imagine Avi does not want it logged for security purposes.
Regards, Patrick
_________________________________________________________________________ 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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Mostly credit cards.. and anything you do with it, e.g. submit it via https to authorize.net, stripe, etc where then you don't need the actual number anymore. So both the DTMF entry and the curl debug line. I can't think of anything else in particular. -Avi On Wed, May 30, 2012 at 11:35 PM, Michael Collins <msc@freeswitch.org>wrote:
Avi,
Can you think of any other places where the FS logging in general might contain sensitive data? Reason I ask is that maybe we could create something like "pcidss=true" and then use that as a flag to disable logging anything that might be considered sensitive. Just a thought.
-MC
On Wed, May 30, 2012 at 1:29 PM, Avi Marcus <avi@avimarcus.net> wrote:
On Wed, May 30, 2012 at 11:18 PM, Michael Collins <msc@freeswitch.org>wrote:
How are you protecting everything else? If the XML CDR is sent over HTTP instead of HTTPS then everything about the call is plain text.
As far as I know, the only thing sensitive in the xml_cdr is digits_dialed.
And what about the FS logs? Are you encrypting those somehow? It seems to me that you need a more comprehensive solution than just scrubbing a single channel variable.
No, I'm not encrypting them.. because t here wouldn't be anything sensitive. As far as I can tell, the only issue is the DTMF in DEBUG and the curl post message, again in DEBUG. Since this is a lua IVR it seems nearly nothing else makes it into the log. Only api:execute("curl",...) is in the log because it's not a native direct curl command (like session:playandgetdigits())
However, if you need an interim solution I would suggest commenting out the line that sets digits_dialed:
http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_channel.c?r=H...
A more permanent solution might be to create a channel variable that controls whether stuff like this gets logged. Something like "no_dtmf_logging=true" or whatever. That's a bit more involved because you have to decide if there are other places where DTMF info gets logged and if so, decide whether or not you want not to log them.
That's an interesting idea... it might be more encompassing to have a loglevel=X channel variable instead that affects the logging for that channel. But this is probably overkill...
What would be the ideal solution for your scenario? That answer might yield the best course of action. -MC
On Wed, May 30, 2012 at 11:20 AM, Avi Marcus <avi@avimarcus.net> wrote:
The PCI-DSS (Payment Card Industry Data Security Standard) requires encryption, not merely permission restriction, for sensitive data. Hence I'm looking at the DTMF logging which can probably be easily re-patterned back into the digits, the curl POST which also shows everything in the log, the dialed_digits in a standard xml_cdr.. Otherwise, afaik, lua won't log things unless you explicitly tell it to.
Any suggestions other than setting the entire switch to fsctl loglevel 6 and not storing the xml_cdrs in their raw form?
-Avi
On Wed, May 30, 2012 at 8:11 PM, Michael Collins <msc@freeswitch.org>wrote:
If it's a compliance issue then I'd triple-check to make sure that no one unauthorized can get to any of your FS logs or CDR data. I suspect that logging vs. not logging dialed_digits is not a make-or-break proposition. If you're doing xml_cdrs then you've probably got that same data in other log lines.
-MC
On Wed, May 30, 2012 at 9:08 AM, Patrick Lists < freeswitch-list@puzzled.xs4all.nl> wrote:
On 30-05-12 17:48, Michael Collins wrote: > And.. similarly is there a way to blank out the var digits_dialed in > the xml_cdr, from within FS, before the end of the call? > > Why do you need to clear it out? What information does it collect that > you don't need?
Since it's credit card data I can imagine Avi does not want it logged for security purposes.
Regards, Patrick
_________________________________________________________________________ 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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Just curious what other companies using FreeSWITCH and taking credit card over the phone are doing? there is no way you can be PCI compliant if you store the logs or CDRs, encrypted or not if it contains the CVV2. same goes for call recording. and iirc you can't use a regular voip line for credit cards (you have to use encryped linnes if it's voip) On 5/30/2012 5:25 PM, Avi Marcus wrote:
Mostly credit cards.. and anything you do with it, e.g. submit it via https to authorize.net <http://authorize.net>, stripe, etc where then you don't need the actual number anymore. So both the DTMF entry and the curl debug line. I can't think of anything else in particular.
-Avi
On Wed, May 30, 2012 at 11:35 PM, Michael Collins <msc@freeswitch.org <mailto:msc@freeswitch.org>> wrote:
Avi,
Can you think of any other places where the FS logging in general might contain sensitive data? Reason I ask is that maybe we could create something like "pcidss=true" and then use that as a flag to disable logging anything that might be considered sensitive. Just a thought.
-MC
On Wed, May 30, 2012 at 1:29 PM, Avi Marcus <avi@avimarcus.net <mailto:avi@avimarcus.net>> wrote:
On Wed, May 30, 2012 at 11:18 PM, Michael Collins <msc@freeswitch.org <mailto:msc@freeswitch.org>> wrote:
How are you protecting everything else? If the XML CDR is sent over HTTP instead of HTTPS then everything about the call is plain text.
As far as I know, the only thing sensitive in the xml_cdr is digits_dialed.
And what about the FS logs? Are you encrypting those somehow? It seems to me that you need a more comprehensive solution than just scrubbing a single channel variable.
No, I'm not encrypting them.. because t here wouldn't be anything sensitive. As far as I can tell, the only issue is the DTMF in DEBUG and the curl post message, again in DEBUG. Since this is a lua IVR it seems nearly nothing else makes it into the log. Only api:execute("curl",...) is in the log because it's not a native direct curl command (like session:playandgetdigits())
However, if you need an interim solution I would suggest commenting out the line that sets digits_dialed: http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_channel.c?r=H...
A more permanent solution might be to create a channel variable that controls whether stuff like this gets logged. Something like "no_dtmf_logging=true" or whatever. That's a bit more involved because you have to decide if there are other places where DTMF info gets logged and if so, decide whether or not you want not to log them.
That's an interesting idea... it might be more encompassing to have a loglevel=X channel variable instead that affects the logging for that channel. But this is probably overkill...
What would be the ideal solution for your scenario? That answer might yield the best course of action. -MC
On Wed, May 30, 2012 at 11:20 AM, Avi Marcus <avi@avimarcus.net <mailto:avi@avimarcus.net>> wrote:
The PCI-DSS (Payment Card Industry Data Security Standard) requires encryption, not merely permission restriction, for sensitive data. Hence I'm looking at the DTMF logging which can probably be easily re-patterned back into the digits, the curl POST which also shows everything in the log, the dialed_digits in a standard xml_cdr.. Otherwise, afaik, lua won't log things unless you explicitly tell it to.
Any suggestions other than setting the entire switch to fsctl loglevel 6 and not storing the xml_cdrs in their raw form?
-Avi
On Wed, May 30, 2012 at 8:11 PM, Michael Collins <msc@freeswitch.org <mailto:msc@freeswitch.org>> wrote:
If it's a compliance issue then I'd triple-check to make sure that no one unauthorized can get to any of your FS logs or CDR data. I suspect that logging vs. not logging dialed_digits is not a make-or-break proposition. If you're doing xml_cdrs then you've probably got that same data in other log lines.
-MC
On Wed, May 30, 2012 at 9:08 AM, Patrick Lists <freeswitch-list@puzzled.xs4all.nl <mailto:freeswitch-list@puzzled.xs4all.nl>> wrote:
On 30-05-12 17:48, Michael Collins wrote: > And.. similarly is there a way to blank out the var digits_dialed in > the xml_cdr, from within FS, before the end of the call? > > Why do you need to clear it out? What information does it collect that > you don't need?
Since it's credit card data I can imagine Avi does not want it logged for security purposes.
Regards, Patrick
_________________________________________________________________________ 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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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 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
Join Us At ClueCon - Aug 7-9, 2012
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
More than likely those companies are somewhat oblivious to that. Its hard to.find a VoIP provider who secures the calls end to end, and they may not realize they are logging digits for the automated IVRs. I would think they are smart enough to not record calls with the CVV. I think some companies probably don't ask for the CVV2, there are some gateways where you can avoid collecting it but pay higher rates for the risk. Brian Foster Endigo Computer LLC Sent from a mobile device. On Jun 7, 2012 12:17 PM, "Abaci" <abaci64@gmail.com> wrote:
Just curious what other companies using FreeSWITCH and taking credit card over the phone are doing? there is no way you can be PCI compliant if you store the logs or CDRs, encrypted or not if it contains the CVV2. same goes for call recording. and iirc you can't use a regular voip line for credit cards (you have to use encryped linnes if it's voip)
On 5/30/2012 5:25 PM, Avi Marcus wrote:
Mostly credit cards.. and anything you do with it, e.g. submit it via https to authorize.net, stripe, etc where then you don't need the actual number anymore. So both the DTMF entry and the curl debug line. I can't think of anything else in particular.
-Avi
On Wed, May 30, 2012 at 11:35 PM, Michael Collins <msc@freeswitch.org>wrote:
Avi,
Can you think of any other places where the FS logging in general might contain sensitive data? Reason I ask is that maybe we could create something like "pcidss=true" and then use that as a flag to disable logging anything that might be considered sensitive. Just a thought.
-MC
On Wed, May 30, 2012 at 1:29 PM, Avi Marcus <avi@avimarcus.net> wrote:
On Wed, May 30, 2012 at 11:18 PM, Michael Collins <msc@freeswitch.org>wrote:
How are you protecting everything else? If the XML CDR is sent over HTTP instead of HTTPS then everything about the call is plain text.
As far as I know, the only thing sensitive in the xml_cdr is digits_dialed.
And what about the FS logs? Are you encrypting those somehow? It seems to me that you need a more comprehensive solution than just scrubbing a single channel variable.
No, I'm not encrypting them.. because t here wouldn't be anything sensitive. As far as I can tell, the only issue is the DTMF in DEBUG and the curl post message, again in DEBUG. Since this is a lua IVR it seems nearly nothing else makes it into the log. Only api:execute("curl",...) is in the log because it's not a native direct curl command (like session:playandgetdigits())
However, if you need an interim solution I would suggest commenting out the line that sets digits_dialed:
http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_channel.c?r=H...
A more permanent solution might be to create a channel variable that controls whether stuff like this gets logged. Something like "no_dtmf_logging=true" or whatever. That's a bit more involved because you have to decide if there are other places where DTMF info gets logged and if so, decide whether or not you want not to log them.
That's an interesting idea... it might be more encompassing to have a loglevel=X channel variable instead that affects the logging for that channel. But this is probably overkill...
What would be the ideal solution for your scenario? That answer might yield the best course of action. -MC
On Wed, May 30, 2012 at 11:20 AM, Avi Marcus <avi@avimarcus.net>wrote:
The PCI-DSS (Payment Card Industry Data Security Standard) requires encryption, not merely permission restriction, for sensitive data. Hence I'm looking at the DTMF logging which can probably be easily re-patterned back into the digits, the curl POST which also shows everything in the log, the dialed_digits in a standard xml_cdr.. Otherwise, afaik, lua won't log things unless you explicitly tell it to.
Any suggestions other than setting the entire switch to fsctl loglevel 6 and not storing the xml_cdrs in their raw form?
-Avi
On Wed, May 30, 2012 at 8:11 PM, Michael Collins <msc@freeswitch.org>wrote:
If it's a compliance issue then I'd triple-check to make sure that no one unauthorized can get to any of your FS logs or CDR data. I suspect that logging vs. not logging dialed_digits is not a make-or-break proposition. If you're doing xml_cdrs then you've probably got that same data in other log lines.
-MC
On Wed, May 30, 2012 at 9:08 AM, Patrick Lists < freeswitch-list@puzzled.xs4all.nl> wrote:
> On 30-05-12 17:48, Michael Collins wrote: > > And.. similarly is there a way to blank out the var > digits_dialed in > > the xml_cdr, from within FS, before the end of the call? > > > > Why do you need to clear it out? What information does it collect > that > > you don't need? > > Since it's credit card data I can imagine Avi does not want it logged > for security purposes. > > Regards, > Patrick >
_________________________________________________________________________ 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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ 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
Join Us At ClueCon - Aug 7-9, 2012
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 had a big thread on Asterisk-biz (after asking here) and basically I didn't hear anyone say they have a secured VoIP channel. Even if they did, there's no way you can guarantee it's encrypted end to end. And some made the point that PSTN is interceptable/hackable too directly at the house so encryption from the Telco may already be too late. Are you saying the full credit card number without CVV2 isn't considered sensitive data at all, and can be saved unencrypted....? -Avi On Thu, Jun 7, 2012 at 7:59 PM, Brian Foster <bdfoster@endigotech.com>wrote:
More than likely those companies are somewhat oblivious to that. Its hard to.find a VoIP provider who secures the calls end to end, and they may not realize they are logging digits for the automated IVRs. I would think they are smart enough to not record calls with the CVV. I think some companies probably don't ask for the CVV2, there are some gateways where you can avoid collecting it but pay higher rates for the risk.
Brian Foster Endigo Computer LLC
Sent from a mobile device. On Jun 7, 2012 12:17 PM, "Abaci" <abaci64@gmail.com> wrote:
Just curious what other companies using FreeSWITCH and taking credit card over the phone are doing? there is no way you can be PCI compliant if you store the logs or CDRs, encrypted or not if it contains the CVV2. same goes for call recording. and iirc you can't use a regular voip line for credit cards (you have to use encryped linnes if it's voip)
On 5/30/2012 5:25 PM, Avi Marcus wrote:
Mostly credit cards.. and anything you do with it, e.g. submit it via https to authorize.net, stripe, etc where then you don't need the actual number anymore. So both the DTMF entry and the curl debug line. I can't think of anything else in particular.
-Avi
On Wed, May 30, 2012 at 11:35 PM, Michael Collins <msc@freeswitch.org>wrote:
Avi,
Can you think of any other places where the FS logging in general might contain sensitive data? Reason I ask is that maybe we could create something like "pcidss=true" and then use that as a flag to disable logging anything that might be considered sensitive. Just a thought.
-MC
On Wed, May 30, 2012 at 1:29 PM, Avi Marcus <avi@avimarcus.net> wrote:
On Wed, May 30, 2012 at 11:18 PM, Michael Collins <msc@freeswitch.org>wrote:
How are you protecting everything else? If the XML CDR is sent over HTTP instead of HTTPS then everything about the call is plain text.
As far as I know, the only thing sensitive in the xml_cdr is digits_dialed.
And what about the FS logs? Are you encrypting those somehow? It seems to me that you need a more comprehensive solution than just scrubbing a single channel variable.
No, I'm not encrypting them.. because t here wouldn't be anything sensitive. As far as I can tell, the only issue is the DTMF in DEBUG and the curl post message, again in DEBUG. Since this is a lua IVR it seems nearly nothing else makes it into the log. Only api:execute("curl",...) is in the log because it's not a native direct curl command (like session:playandgetdigits())
However, if you need an interim solution I would suggest commenting out the line that sets digits_dialed:
http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_channel.c?r=H...
A more permanent solution might be to create a channel variable that controls whether stuff like this gets logged. Something like "no_dtmf_logging=true" or whatever. That's a bit more involved because you have to decide if there are other places where DTMF info gets logged and if so, decide whether or not you want not to log them.
That's an interesting idea... it might be more encompassing to have a loglevel=X channel variable instead that affects the logging for that channel. But this is probably overkill...
What would be the ideal solution for your scenario? That answer might yield the best course of action. -MC
On Wed, May 30, 2012 at 11:20 AM, Avi Marcus <avi@avimarcus.net>wrote:
The PCI-DSS (Payment Card Industry Data Security Standard) requires encryption, not merely permission restriction, for sensitive data. Hence I'm looking at the DTMF logging which can probably be easily re-patterned back into the digits, the curl POST which also shows everything in the log, the dialed_digits in a standard xml_cdr.. Otherwise, afaik, lua won't log things unless you explicitly tell it to.
Any suggestions other than setting the entire switch to fsctl loglevel 6 and not storing the xml_cdrs in their raw form?
-Avi
On Wed, May 30, 2012 at 8:11 PM, Michael Collins <msc@freeswitch.org>wrote:
> If it's a compliance issue then I'd triple-check to make sure that > no one unauthorized can get to any of your FS logs or CDR data. I suspect > that logging vs. not logging dialed_digits is not a make-or-break > proposition. If you're doing xml_cdrs then you've probably got that same > data in other log lines. > > -MC > > > On Wed, May 30, 2012 at 9:08 AM, Patrick Lists < > freeswitch-list@puzzled.xs4all.nl> wrote: > >> On 30-05-12 17:48, Michael Collins wrote: >> > And.. similarly is there a way to blank out the var >> digits_dialed in >> > the xml_cdr, from within FS, before the end of the call? >> > >> > Why do you need to clear it out? What information does it collect >> that >> > you don't need? >> >> Since it's credit card data I can imagine Avi does not want it >> logged >> for security purposes. >> >> Regards, >> Patrick >> > > > > _________________________________________________________________________ > 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 > > Join Us At ClueCon - Aug 7-9, 2012 > > 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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ 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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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
According to the PCI DSS normative, you can store the PAN if it is encrypted. You must have a separate process in place governing the encryption (key storage, key rotation, key access, etc.) However you can't, under any circumstances, store the CVV/CVV2 digits. Never. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Avi Marcus Sent: Thursday, June 07, 2012 5:37 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Per-channel fsctl loglevel? I had a big thread on Asterisk-biz (after asking here) and basically I didn't hear anyone say they have a secured VoIP channel. Even if they did, there's no way you can guarantee it's encrypted end to end. And some made the point that PSTN is interceptable/hackable too directly at the house so encryption from the Telco may already be too late. Are you saying the full credit card number without CVV2 isn't considered sensitive data at all, and can be saved unencrypted....? -Avi On Thu, Jun 7, 2012 at 7:59 PM, Brian Foster <bdfoster@endigotech.com<mailto:bdfoster@endigotech.com>> wrote: More than likely those companies are somewhat oblivious to that. Its hard to.find a VoIP provider who secures the calls end to end, and they may not realize they are logging digits for the automated IVRs. I would think they are smart enough to not record calls with the CVV. I think some companies probably don't ask for the CVV2, there are some gateways where you can avoid collecting it but pay higher rates for the risk. Brian Foster Endigo Computer LLC Sent from a mobile device. On Jun 7, 2012 12:17 PM, "Abaci" <abaci64@gmail.com<mailto:abaci64@gmail.com>> wrote: Just curious what other companies using FreeSWITCH and taking credit card over the phone are doing? there is no way you can be PCI compliant if you store the logs or CDRs, encrypted or not if it contains the CVV2. same goes for call recording. and iirc you can't use a regular voip line for credit cards (you have to use encryped linnes if it's voip) On 5/30/2012 5:25 PM, Avi Marcus wrote: Mostly credit cards.. and anything you do with it, e.g. submit it via https to authorize.net<http://authorize.net>, stripe, etc where then you don't need the actual number anymore. So both the DTMF entry and the curl debug line. I can't think of anything else in particular. -Avi On Wed, May 30, 2012 at 11:35 PM, Michael Collins <msc@freeswitch.org<mailto:msc@freeswitch.org>> wrote: Avi, Can you think of any other places where the FS logging in general might contain sensitive data? Reason I ask is that maybe we could create something like "pcidss=true" and then use that as a flag to disable logging anything that might be considered sensitive. Just a thought. -MC On Wed, May 30, 2012 at 1:29 PM, Avi Marcus <avi@avimarcus.net<mailto:avi@avimarcus.net>> wrote: On Wed, May 30, 2012 at 11:18 PM, Michael Collins <msc@freeswitch.org<mailto:msc@freeswitch.org>> wrote: How are you protecting everything else? If the XML CDR is sent over HTTP instead of HTTPS then everything about the call is plain text. As far as I know, the only thing sensitive in the xml_cdr is digits_dialed. And what about the FS logs? Are you encrypting those somehow? It seems to me that you need a more comprehensive solution than just scrubbing a single channel variable. No, I'm not encrypting them.. because t here wouldn't be anything sensitive. As far as I can tell, the only issue is the DTMF in DEBUG and the curl post message, again in DEBUG. Since this is a lua IVR it seems nearly nothing else makes it into the log. Only api:execute("curl",...) is in the log because it's not a native direct curl command (like session:playandgetdigits()) However, if you need an interim solution I would suggest commenting out the line that sets digits_dialed: http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_channel.c?r=H... A more permanent solution might be to create a channel variable that controls whether stuff like this gets logged. Something like "no_dtmf_logging=true" or whatever. That's a bit more involved because you have to decide if there are other places where DTMF info gets logged and if so, decide whether or not you want not to log them. That's an interesting idea... it might be more encompassing to have a loglevel=X channel variable instead that affects the logging for that channel. But this is probably overkill... What would be the ideal solution for your scenario? That answer might yield the best course of action. -MC On Wed, May 30, 2012 at 11:20 AM, Avi Marcus <avi@avimarcus.net<mailto:avi@avimarcus.net>> wrote: The PCI-DSS (Payment Card Industry Data Security Standard) requires encryption, not merely permission restriction, for sensitive data. Hence I'm looking at the DTMF logging which can probably be easily re-patterned back into the digits, the curl POST which also shows everything in the log, the dialed_digits in a standard xml_cdr.. Otherwise, afaik, lua won't log things unless you explicitly tell it to. Any suggestions other than setting the entire switch to fsctl loglevel 6 and not storing the xml_cdrs in their raw form? -Avi On Wed, May 30, 2012 at 8:11 PM, Michael Collins <msc@freeswitch.org<mailto:msc@freeswitch.org>> wrote: If it's a compliance issue then I'd triple-check to make sure that no one unauthorized can get to any of your FS logs or CDR data. I suspect that logging vs. not logging dialed_digits is not a make-or-break proposition. If you're doing xml_cdrs then you've probably got that same data in other log lines. -MC On Wed, May 30, 2012 at 9:08 AM, Patrick Lists <freeswitch-list@puzzled.xs4all.nl<mailto:freeswitch-list@puzzled.xs4all.nl>> wrote: On 30-05-12 17:48, Michael Collins wrote:
And.. similarly is there a way to blank out the var digits_dialed in the xml_cdr, from within FS, before the end of the call?
Why do you need to clear it out? What information does it collect that you don't need?
Since it's credit card data I can imagine Avi does not want it logged for security purposes. Regards, Patrick _________________________________________________________________________ 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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
http://jira.freeswitch.org/browse/FS-4709 From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Hector Geraldino Sent: Thursday, June 07, 2012 6:02 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Per-channel fsctl loglevel? According to the PCI DSS normative, you can store the PAN if it is encrypted. You must have a separate process in place governing the encryption (key storage, key rotation, key access, etc.) However you can't, under any circumstances, store the CVV/CVV2 digits. Never. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Avi Marcus Sent: Thursday, June 07, 2012 5:37 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Per-channel fsctl loglevel? I had a big thread on Asterisk-biz (after asking here) and basically I didn't hear anyone say they have a secured VoIP channel. Even if they did, there's no way you can guarantee it's encrypted end to end. And some made the point that PSTN is interceptable/hackable too directly at the house so encryption from the Telco may already be too late. Are you saying the full credit card number without CVV2 isn't considered sensitive data at all, and can be saved unencrypted....? -Avi On Thu, Jun 7, 2012 at 7:59 PM, Brian Foster <bdfoster@endigotech.com> wrote: More than likely those companies are somewhat oblivious to that. Its hard to.find a VoIP provider who secures the calls end to end, and they may not realize they are logging digits for the automated IVRs. I would think they are smart enough to not record calls with the CVV. I think some companies probably don't ask for the CVV2, there are some gateways where you can avoid collecting it but pay higher rates for the risk. Brian Foster Endigo Computer LLC Sent from a mobile device. On Jun 7, 2012 12:17 PM, "Abaci" <abaci64@gmail.com> wrote: Just curious what other companies using FreeSWITCH and taking credit card over the phone are doing? there is no way you can be PCI compliant if you store the logs or CDRs, encrypted or not if it contains the CVV2. same goes for call recording. and iirc you can't use a regular voip line for credit cards (you have to use encryped linnes if it's voip) On 5/30/2012 5:25 PM, Avi Marcus wrote: Mostly credit cards.. and anything you do with it, e.g. submit it via https to authorize.net, stripe, etc where then you don't need the actual number anymore. So both the DTMF entry and the curl debug line. I can't think of anything else in particular. -Avi On Wed, May 30, 2012 at 11:35 PM, Michael Collins <msc@freeswitch.org> wrote: Avi, Can you think of any other places where the FS logging in general might contain sensitive data? Reason I ask is that maybe we could create something like "pcidss=true" and then use that as a flag to disable logging anything that might be considered sensitive. Just a thought. -MC On Wed, May 30, 2012 at 1:29 PM, Avi Marcus <avi@avimarcus.net> wrote: On Wed, May 30, 2012 at 11:18 PM, Michael Collins <msc@freeswitch.org> wrote: How are you protecting everything else? If the XML CDR is sent over HTTP instead of HTTPS then everything about the call is plain text. As far as I know, the only thing sensitive in the xml_cdr is digits_dialed. And what about the FS logs? Are you encrypting those somehow? It seems to me that you need a more comprehensive solution than just scrubbing a single channel variable. No, I'm not encrypting them.. because t here wouldn't be anything sensitive. As far as I can tell, the only issue is the DTMF in DEBUG and the curl post message, again in DEBUG. Since this is a lua IVR it seems nearly nothing else makes it into the log. Only api:execute("curl",...) is in the log because it's not a native direct curl command (like session:playandgetdigits()) However, if you need an interim solution I would suggest commenting out the line that sets digits_dialed: http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_channel.c?r=H EAD#to3912 A more permanent solution might be to create a channel variable that controls whether stuff like this gets logged. Something like "no_dtmf_logging=true" or whatever. That's a bit more involved because you have to decide if there are other places where DTMF info gets logged and if so, decide whether or not you want not to log them. That's an interesting idea... it might be more encompassing to have a loglevel=X channel variable instead that affects the logging for that channel. But this is probably overkill... What would be the ideal solution for your scenario? That answer might yield the best course of action. -MC On Wed, May 30, 2012 at 11:20 AM, Avi Marcus <avi@avimarcus.net> wrote: The PCI-DSS (Payment Card Industry Data Security Standard) requires encryption, not merely permission restriction, for sensitive data. Hence I'm looking at the DTMF logging which can probably be easily re-patterned back into the digits, the curl POST which also shows everything in the log, the dialed_digits in a standard xml_cdr.. Otherwise, afaik, lua won't log things unless you explicitly tell it to. Any suggestions other than setting the entire switch to fsctl loglevel 6 and not storing the xml_cdrs in their raw form? -Avi On Wed, May 30, 2012 at 8:11 PM, Michael Collins <msc@freeswitch.org> wrote: If it's a compliance issue then I'd triple-check to make sure that no one unauthorized can get to any of your FS logs or CDR data. I suspect that logging vs. not logging dialed_digits is not a make-or-break proposition. If you're doing xml_cdrs then you've probably got that same data in other log lines. -MC On Wed, May 30, 2012 at 9:08 AM, Patrick Lists <freeswitch-list@puzzled.xs4all.nl> wrote: On 30-05-12 17:48, Michael Collins wrote:
And.. similarly is there a way to blank out the var digits_dialed in the xml_cdr, from within FS, before the end of the call?
Why do you need to clear it out? What information does it collect that you don't need?
Since it's credit card data I can imagine Avi does not want it logged for security purposes. Regards, Patrick _________________________________________________________________________ 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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 Join Us At ClueCon - Aug 7-9, 2012 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
participants (7)
-
Abaci
-
Avi Marcus
-
Brian Foster
-
Hector Geraldino
-
Michael Collins
-
moshe3
-
Patrick Lists