How to reject a call and not log it in CDRs that contains unsupported ANCII characters?
Hello all, Maybe someone can help me with this problem and will be greatly appreciated. We are getting calls with CallerID like this one ‘hi'or‘x’='x'. Later when our billing start parsing the CDRs it will complain because of the first character "`". My question I suppose is, how to prevent such calls to get added to the CDRs? We want to reject the call that has non numeric CallerID and not get it added in the CDRs. This is what we have in the dialplan. <extension name="Routing"> <condition field="${radius_auth_result}" expression="0"/> <!-- <condition field="${h323-redirect-number}" expression="^(.+)$" break="never"> <action application="set" data="destination_number=$1" /> </condition> --> <condition field="caller_id_number" expression="^([0-9]+)$"> <anti-action application="hangup"/> </condition> <condition field="destination_number" expression="^(.+)$"> <!--<action application="info"/>--> <action application="export" data="nolocal:h323-call-origin=originate"/> <action application="set" data="sip_h_X-accountcode=${accountcode}" /> <action application="set" data="call_direction=outbound" /> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="inherit_codec=true" /> <action application="set" data="call_timeout=20"/> <action application="set" data="fail_on_single_reject=USER_BUSY" /> <action application="set" data="origination_caller_id_name=${sip_req_user}"/> <action application="set" data="origination_caller_id_number=${sip_from_user}"/> <action application="set" data="execute_on_answer=sched_hangup +${h323-credit-time} alloted_timeout" /> <action application="bridge" data="{sip_invite_from_uri=sip:${sip_from_user}@ ${sip_network_ip}}sofia/internal/${destination_number}@x.x.x.x:5060" /> <action application="hangup" data="${bridge_hangup_cause}"/> </condition> </extension> Thank you all! L.Popov <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Hi Lyubo, In this case it may be better to see if your CDR parser can skip the non-numeric caller id values, perhaps by adding a validation check prior to performing the parse action. As a rule of thumb, if your CDR parser can be tripped up by the data it is parsing then it needs to be hardened. I'm sure many here would highly recommend sanitizing/validation as a best practice, particularly when handling data that comes from the public Internet. Another consideration is that you may actually want to have a record of these kinds of attacks in case there is a need to investigate an incident or otherwise analyze attack patterns. I would recommend that you change the behavior of the parser from "complaining" to "keeping the CDR database clean but logging invalid input for future reference." Hope this helps, -MC On Fri, Dec 15, 2017 at 1:11 PM, Lyubo Popov <koki.roul@gmail.com> wrote:
Hello all,
Maybe someone can help me with this problem and will be greatly appreciated. We are getting calls with CallerID like this one ‘hi'or‘x’='x'. Later when our billing start parsing the CDRs it will complain because of the first character "`". My question I suppose is, how to prevent such calls to get added to the CDRs? We want to reject the call that has non numeric CallerID and not get it added in the CDRs. This is what we have in the dialplan.
<extension name="Routing"> <condition field="${radius_auth_result}" expression="0"/>
<!-- <condition field="${h323-redirect-number}" expression="^(.+)$" break="never"> <action application="set" data="destination_number=$1" /> </condition> --> <condition field="caller_id_number" expression="^([0-9]+)$"> <anti-action application="hangup"/> </condition> <condition field="destination_number" expression="^(.+)$"> <!--<action application="info"/>--> <action application="export" data="nolocal:h323-call- origin=originate"/> <action application="set" data="sip_h_X-accountcode=${accountcode}" /> <action application="set" data="call_direction=outbound" /> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="inherit_codec=true" /> <action application="set" data="call_timeout=20"/> <action application="set" data="fail_on_single_reject=USER_BUSY" /> <action application="set" data="origination_caller_id_ name=${sip_req_user}"/> <action application="set" data="origination_caller_id_ number=${sip_from_user}"/> <action application="set" data="execute_on_answer=sched_hangup +${h323-credit-time} alloted_timeout" /> <action application="bridge" data="{sip_invite_from_uri= sip:${sip_from_user}@${sip_network_ip}}sofia/internal/${ destination_number}@x.x.x.x:5060" /> <action application="hangup" data="${bridge_hangup_cause}"/> </condition> </extension>
Thank you all!
L.Popov
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#m_-7626445720286026976_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Hi, Lyubo! I had similar case. Use process_cdr variable in dialplan, if you do not want to store in CDR. <action application="set" data="process_cdr= false "/> Hope it helps, Gregor 2017-12-18 21:44 GMT+01:00 Michael Collins <msc@freeswitch.org>:
Hi Lyubo,
In this case it may be better to see if your CDR parser can skip the non-numeric caller id values, perhaps by adding a validation check prior to performing the parse action. As a rule of thumb, if your CDR parser can be tripped up by the data it is parsing then it needs to be hardened. I'm sure many here would highly recommend sanitizing/validation as a best practice, particularly when handling data that comes from the public Internet. Another consideration is that you may actually want to have a record of these kinds of attacks in case there is a need to investigate an incident or otherwise analyze attack patterns.
I would recommend that you change the behavior of the parser from "complaining" to "keeping the CDR database clean but logging invalid input for future reference."
Hope this helps, -MC
On Fri, Dec 15, 2017 at 1:11 PM, Lyubo Popov <koki.roul@gmail.com> wrote:
Hello all,
Maybe someone can help me with this problem and will be greatly appreciated. We are getting calls with CallerID like this one ‘hi'or‘x’='x'. Later when our billing start parsing the CDRs it will complain because of the first character "`". My question I suppose is, how to prevent such calls to get added to the CDRs? We want to reject the call that has non numeric CallerID and not get it added in the CDRs. This is what we have in the dialplan.
<extension name="Routing"> <condition field="${radius_auth_result}" expression="0"/>
<!-- <condition field="${h323-redirect-number}" expression="^(.+)$" break="never"> <action application="set" data="destination_number=$1" /> </condition> --> <condition field="caller_id_number" expression="^([0-9]+)$"> <anti-action application="hangup"/> </condition> <condition field="destination_number" expression="^(.+)$"> <!--<action application="info"/>--> <action application="export" data="nolocal:h323-call-origin =originate"/> <action application="set" data="sip_h_X-accountcode=${accountcode}" /> <action application="set" data="call_direction=outbound" /> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="inherit_codec=true" /> <action application="set" data="call_timeout=20"/> <action application="set" data="fail_on_single_reject=USER_BUSY" /> <action application="set" data="origination_caller_id_na me=${sip_req_user}"/> <action application="set" data="origination_caller_id_nu mber=${sip_from_user}"/> <action application="set" data="execute_on_answer=sched_hangup +${h323-credit-time} alloted_timeout" /> <action application="bridge" data="{sip_invite_from_uri=sip :${sip_from_user}@${sip_network_ip}}sofia/internal/${destina tion_number}@x.x.x.x:5060" /> <action application="hangup" data="${bridge_hangup_cause}"/> </condition> </extension>
Thank you all!
L.Popov
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#m_2040158889290273727_m_-7626445720286026976_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- Gregor Nanger *CTO* t./f.: 00386 (0) 7 6000 308/309 • m:. 00386 (0)41 756485 • Infomedia d.o.o. • Jerebova 3, Novo mesto, Slovenia • www.infomedia.si
Thank you very much for the reply. The process_cdr variable is very useful and exactly what I was looking for. Appreciated! <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Mon, Dec 18, 2017 at 8:37 PM, Gregor Nanger <gregor@infomedia.si> wrote:
Hi, Lyubo!
I had similar case. Use process_cdr variable in dialplan, if you do not want to store in CDR.
<action application="set" data="process_cdr= false "/>
Hope it helps, Gregor
2017-12-18 21:44 GMT+01:00 Michael Collins <msc@freeswitch.org>:
Hi Lyubo,
In this case it may be better to see if your CDR parser can skip the non-numeric caller id values, perhaps by adding a validation check prior to performing the parse action. As a rule of thumb, if your CDR parser can be tripped up by the data it is parsing then it needs to be hardened. I'm sure many here would highly recommend sanitizing/validation as a best practice, particularly when handling data that comes from the public Internet. Another consideration is that you may actually want to have a record of these kinds of attacks in case there is a need to investigate an incident or otherwise analyze attack patterns.
I would recommend that you change the behavior of the parser from "complaining" to "keeping the CDR database clean but logging invalid input for future reference."
Hope this helps, -MC
On Fri, Dec 15, 2017 at 1:11 PM, Lyubo Popov <koki.roul@gmail.com> wrote:
Hello all,
Maybe someone can help me with this problem and will be greatly appreciated. We are getting calls with CallerID like this one ‘hi'or‘x’='x'. Later when our billing start parsing the CDRs it will complain because of the first character "`". My question I suppose is, how to prevent such calls to get added to the CDRs? We want to reject the call that has non numeric CallerID and not get it added in the CDRs. This is what we have in the dialplan.
<extension name="Routing"> <condition field="${radius_auth_result}" expression="0"/>
<!-- <condition field="${h323-redirect-number}" expression="^(.+)$" break="never"> <action application="set" data="destination_number=$1" /> </condition> --> <condition field="caller_id_number" expression="^([0-9]+)$"> <anti-action application="hangup"/> </condition> <condition field="destination_number" expression="^(.+)$"> <!--<action application="info"/>--> <action application="export" data="nolocal:h323-call-origin =originate"/> <action application="set" data="sip_h_X-accountcode=${accountcode}" /> <action application="set" data="call_direction=outbound" /> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="inherit_codec=true" /> <action application="set" data="call_timeout=20"/> <action application="set" data="fail_on_single_reject=USER_BUSY" /> <action application="set" data="origination_caller_id_na me=${sip_req_user}"/> <action application="set" data="origination_caller_id_nu mber=${sip_from_user}"/> <action application="set" data="execute_on_answer=sched_hangup +${h323-credit-time} alloted_timeout" /> <action application="bridge" data="{sip_invite_from_uri=sip :${sip_from_user}@${sip_network_ip}}sofia/internal/${destina tion_number}@x.x.x.x:5060" /> <action application="hangup" data="${bridge_hangup_cause}"/> </condition> </extension>
Thank you all!
L.Popov
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#m_2242263481946948631_m_2040158889290273727_m_-7626445720286026976_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
____________________________________________________________ _____________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- Gregor Nanger
*CTO* t./f.: 00386 (0) 7 6000 308/309 • m:. 00386 (0)41 756485 • Infomedia d.o.o. • Jerebova 3, Novo mesto, Slovenia • www.infomedia.si
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- Atenciosamente, ============================ Lyubo Popov CEO - BlasterPhone LLC Tel: 4003-1556 ( Outside Brazil 55 11 4003-1556) iNum: +883 510001-354111 Website: http://www.blastervoip.com.br/ ============================
Glad to help. Just be carefull, if you also would like to use b_only. It only works if you also have b leg loging enabled in conf file. On Wed, Dec 20, 2017, 03:01 Lyubo Popov <lpopov@blasterphone.com <https://mltrk.io/link/mailto%3Alpopov%40blasterphone.com/jCUwHkcTexx2TytmrpF6>> wrote:
Thank you very much for the reply. The process_cdr variable is very useful and exactly what I was looking for. Appreciated!
<https://mltrk.io/link/https%3A%2F%2Fwww.avast.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Dwebmail%26utm_term%3Dicon/jCUwHkcTexx2TytmrpF6> Virus-free. www.avast.com <https://mltrk.io/link/https%3A%2F%2Fwww.avast.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Dwebmail%26utm_term%3Dlink/jCUwHkcTexx2TytmrpF6> <https://mltrk.io/link/%23m_926543164795071026_m_-8463921194330766450_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2/jCUwHkcTexx2TytmrpF6>
On Mon, Dec 18, 2017 at 8:37 PM, Gregor Nanger <gregor@infomedia.si <https://mltrk.io/link/mailto%3Agregor%40infomedia.si/jCUwHkcTexx2TytmrpF6>
wrote:
Hi, Lyubo!
I had similar case. Use process_cdr variable in dialplan, if you do not want to store in CDR.
<action application="set" data="process_cdr= false "/>
Hope it helps, Gregor
2017-12-18 21:44 GMT+01:00 Michael Collins <msc@freeswitch.org <https://mltrk.io/link/mailto%3Amsc%40freeswitch.org/jCUwHkcTexx2TytmrpF6>
:
Hi Lyubo,
In this case it may be better to see if your CDR parser can skip the non-numeric caller id values, perhaps by adding a validation check prior to performing the parse action. As a rule of thumb, if your CDR parser can be tripped up by the data it is parsing then it needs to be hardened. I'm sure many here would highly recommend sanitizing/validation as a best practice, particularly when handling data that comes from the public Internet. Another consideration is that you may actually want to have a record of these kinds of attacks in case there is a need to investigate an incident or otherwise analyze attack patterns.
I would recommend that you change the behavior of the parser from "complaining" to "keeping the CDR database clean but logging invalid input for future reference."
Hope this helps, -MC
On Fri, Dec 15, 2017 at 1:11 PM, Lyubo Popov <koki.roul@gmail.com <https://mltrk.io/link/mailto%3Akoki.roul%40gmail.com/jCUwHkcTexx2TytmrpF6>
wrote:
Hello all,
Maybe someone can help me with this problem and will be greatly appreciated. We are getting calls with CallerID like this one ‘hi'or‘x’='x'. Later when our billing start parsing the CDRs it will complain because of the first character "`". My question I suppose is, how to prevent such calls to get added to the CDRs? We want to reject the call that has non numeric CallerID and not get it added in the CDRs. This is what we have in the dialplan.
<extension name="Routing"> <condition field="${radius_auth_result}" expression="0"/>
<!-- <condition field="${h323-redirect-number}" expression="^(.+)$" break="never"> <action application="set" data="destination_number=$1" /> </condition> --> <condition field="caller_id_number" expression="^([0-9]+)$"> <anti-action application="hangup"/> </condition> <condition field="destination_number" expression="^(.+)$"> <!--<action application="info"/>--> <action application="export" data="nolocal:h323-call- origin=originate"/> <action application="set" data="sip_h_X-accountcode=${accountcode}" /> <action application="set" data="call_direction=outbound" /> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="inherit_codec=true" /> <action application="set" data="call_timeout=20"/> <action application="set" data="fail_on_single_reject=USER_BUSY" /> <action application="set" data="origination_caller_id_ name=${sip_req_user}"/> <action application="set" data="origination_caller_id_ number=${sip_from_user}"/> <action application="set" data="execute_on_answer=sched_hangup +${h323-credit-time} alloted_timeout" /> <action application="bridge" data="{sip_invite_from_uri= sip:${sip_from_user}@${sip_network_ip}}sofia/internal/${ destination_number}@x.x.x.x:5060" /> <action application="hangup" data="${bridge_hangup_cause}"/
</condition> </extension>
Thank you all!
L.Popov
<https://mltrk.io/link/https%3A%2F%2Fwww.avast.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Dwebmail%26utm_term%3Dicon/jCUwHkcTexx2TytmrpF6> Virus-free. www.avast.com <https://mltrk.io/link/https%3A%2F%2Fwww.avast.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Dwebmail%26utm_term%3Dlink/jCUwHkcTexx2TytmrpF6> <https://mltrk.io/link/%23m_926543164795071026_m_-8463921194330766450_m_2242263481946948631_m_2040158889290273727_m_-7626445720286026976_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2/jCUwHkcTexx2TytmrpF6>
____________________________________________________________ _____________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <https://mltrk.io/link/mailto%3Aconsulting%40freeswitch.org/jCUwHkcTexx2TytmrpF6>
<https://mltrk.io/link/http%3A%2F%2Fwww.freeswitchsolutions.com/jCUwHkcTexx2TytmrpF6> http://www <https://mltrk.io/link/http%3A%2F%2Fwww/jCUwHkcTexx2TytmrpF6>. freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org <https://mltrk.io/link/http%3A%2F%2Fwww.freeswitch.org/jCUwHkcTexx2TytmrpF6>
<https://mltrk.io/link/http%3A%2F%2Fconfluence.freeswitch.org/jCUwHkcTexx2TytmrpF6> http://confluence.freeswitch <https://mltrk.io/link/http%3A%2F%2Fconfluence.freeswitch/jCUwHkcTexx2TytmrpF6> .org http://www.cluecon.com <https://mltrk.io/link/http%3A%2F%2Fwww.cluecon.com/jCUwHkcTexx2TytmrpF6>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <https://mltrk.io/link/mailto%3AFreeSWITCH-users%40lists.freeswitch.org/jCUwHkcTexx2TytmrpF6>
<https://mltrk.io/link/http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users/jCUwHkcTexx2TytmrpF6> http://lists.freeswitch.org/ <https://mltrk.io/link/http%3A%2F%2Flists.freeswitch.org%2F/jCUwHkcTexx2TytmrpF6> mailman/listinfo/freeswitch-users UNSUBSCRIBE: <https://mltrk.io/link/http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users/jCUwHkcTexx2TytmrpF6> http://lists <https://mltrk.io/link/http%3A%2F%2Flists/jCUwHkcTexx2TytmrpF6>. freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org <https://mltrk.io/link/http%3A%2F%2Fwww.freeswitch.org/jCUwHkcTexx2TytmrpF6>
____________________________________________________________ _____________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <https://mltrk.io/link/mailto%3Aconsulting%40freeswitch.org/jCUwHkcTexx2TytmrpF6>
<https://mltrk.io/link/http%3A%2F%2Fwww.freeswitchsolutions.com/jCUwHkcTexx2TytmrpF6> http://www <https://mltrk.io/link/http%3A%2F%2Fwww/jCUwHkcTexx2TytmrpF6> .freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org <https://mltrk.io/link/http%3A%2F%2Fwww.freeswitch.org/jCUwHkcTexx2TytmrpF6>
<https://mltrk.io/link/http%3A%2F%2Fconfluence.freeswitch.org/jCUwHkcTexx2TytmrpF6> http://confluence.freeswitch <https://mltrk.io/link/http%3A%2F%2Fconfluence.freeswitch/jCUwHkcTexx2TytmrpF6> .org http://www.cluecon.com <https://mltrk.io/link/http%3A%2F%2Fwww.cluecon.com/jCUwHkcTexx2TytmrpF6>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <https://mltrk.io/link/mailto%3AFreeSWITCH-users%40lists.freeswitch.org/jCUwHkcTexx2TytmrpF6>
<https://mltrk.io/link/http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users/jCUwHkcTexx2TytmrpF6> http://lists.freeswitch.org/ <https://mltrk.io/link/http%3A%2F%2Flists.freeswitch.org%2F/jCUwHkcTexx2TytmrpF6> mailman/listinfo/freeswitch-users UNSUBSCRIBE: <https://mltrk.io/link/http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users/jCUwHkcTexx2TytmrpF6> http://lists <https://mltrk.io/link/http%3A%2F%2Flists/jCUwHkcTexx2TytmrpF6>. freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org <https://mltrk.io/link/http%3A%2F%2Fwww.freeswitch.org/jCUwHkcTexx2TytmrpF6>
-- Gregor Nanger
*CTO* t./f.: 00386 (0) 7 6000 308/309 • m:. 00386 (0)41 756485 • Infomedia d.o.o. • Jerebova 3, Novo mesto, Slovenia • www.infomedia.si <https://mltrk.io/link/http%3A%2F%2Fwww.infomedia.si/jCUwHkcTexx2TytmrpF6>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <https://mltrk.io/link/mailto%3Aconsulting%40freeswitch.org/jCUwHkcTexx2TytmrpF6>
<https://mltrk.io/link/http%3A%2F%2Fwww.freeswitchsolutions.com/jCUwHkcTexx2TytmrpF6> http://www <https://mltrk.io/link/http%3A%2F%2Fwww/jCUwHkcTexx2TytmrpF6>. freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org <https://mltrk.io/link/http%3A%2F%2Fwww.freeswitch.org/jCUwHkcTexx2TytmrpF6>
<https://mltrk.io/link/http%3A%2F%2Fconfluence.freeswitch.org/jCUwHkcTexx2TytmrpF6> http://confluence.freeswitch <https://mltrk.io/link/http%3A%2F%2Fconfluence.freeswitch/jCUwHkcTexx2TytmrpF6> .org http://www.cluecon.com <https://mltrk.io/link/http%3A%2F%2Fwww.cluecon.com/jCUwHkcTexx2TytmrpF6>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <https://mltrk.io/link/mailto%3AFreeSWITCH-users%40lists.freeswitch.org/jCUwHkcTexx2TytmrpF6>
<https://mltrk.io/link/http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users/jCUwHkcTexx2TytmrpF6> http://lists.freeswitch.org/ <https://mltrk.io/link/http%3A%2F%2Flists.freeswitch.org%2F/jCUwHkcTexx2TytmrpF6> mailman/listinfo/freeswitch-users UNSUBSCRIBE: <https://mltrk.io/link/http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users/jCUwHkcTexx2TytmrpF6> http://lists <https://mltrk.io/link/http%3A%2F%2Flists/jCUwHkcTexx2TytmrpF6>. freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org <https://mltrk.io/link/http%3A%2F%2Fwww.freeswitch.org/jCUwHkcTexx2TytmrpF6>
-- Atenciosamente, ============================ Lyubo Popov CEO - BlasterPhone LLC Tel: 4003-1556 ( Outside Brazil 55 11 4003-1556) iNum: +883 510001-354111 <https://mltrk.io/link/tel%3A%2B883%2520510%2520001%2520354%2520111/jCUwHkcTexx2TytmrpF6> Website: http://www.blastervoip.com.br/ <https://mltrk.io/link/http%3A%2F%2Fwww.blastervoip.com.br%2F/jCUwHkcTexx2TytmrpF6> ============================ _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <https://mltrk.io/link/mailto%3Aconsulting%40freeswitch.org/jCUwHkcTexx2TytmrpF6>
<https://mltrk.io/link/http%3A%2F%2Fwww.freeswitchsolutions.com/jCUwHkcTexx2TytmrpF6> http://www <https://mltrk.io/link/http%3A%2F%2Fwww/jCUwHkcTexx2TytmrpF6>. freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org <https://mltrk.io/link/http%3A%2F%2Fwww.freeswitch.org/jCUwHkcTexx2TytmrpF6>
<https://mltrk.io/link/http%3A%2F%2Fconfluence.freeswitch.org/jCUwHkcTexx2TytmrpF6> http://confluence.freeswitch <https://mltrk.io/link/http%3A%2F%2Fconfluence.freeswitch/jCUwHkcTexx2TytmrpF6> .org http://www.cluecon.com <https://mltrk.io/link/http%3A%2F%2Fwww.cluecon.com/jCUwHkcTexx2TytmrpF6>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <https://mltrk.io/link/mailto%3AFreeSWITCH-users%40lists.freeswitch.org/jCUwHkcTexx2TytmrpF6>
<https://mltrk.io/link/http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Flistinfo%2Ffreeswitch-users/jCUwHkcTexx2TytmrpF6> http://lists.freeswitch.org/ <https://mltrk.io/link/http%3A%2F%2Flists.freeswitch.org%2F/jCUwHkcTexx2TytmrpF6> mailman/listinfo/freeswitch-users UNSUBSCRIBE: <https://mltrk.io/link/http%3A%2F%2Flists.freeswitch.org%2Fmailman%2Foptions%2Ffreeswitch-users/jCUwHkcTexx2TytmrpF6> http://lists <https://mltrk.io/link/http%3A%2F%2Flists/jCUwHkcTexx2TytmrpF6>. freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org <https://mltrk.io/link/http%3A%2F%2Fwww.freeswitch.org/jCUwHkcTexx2TytmrpF6>
participants (4)
-
Gregor Nanger
-
Lyubo Popov
-
Lyubo Popov
-
Michael Collins