[Freeswitch-users] How to reject a call and not log it in CDRs that contains unsupported ANCII characters?

Wed Dec 20 01:58:20 UTC 2017

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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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/
============================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20171219/cfaba747/attachment.html>