[Freeswitch-users] Direct inward dialling

RR ranjtech at gmail.com
Wed May 26 23:07:34 PDT 2010


hi Mike,

no these are calls coming into our network as a result of people calling the
DIDs we own and they all terminate into the FS serving as a call
distributor. Since a lot of these DIDs are International, we get the numbers
come to us in all sorts of weird formats so I needed to normalise them all
by removing all sorts of weird stuff and prefixes from them

Cheers
RR

On Wed, May 26, 2010 at 5:41 PM, Michael Jerris <mike at jerris.com> wrote:

> are these calls to a registering gateway?
>
> On May 26, 2010, at 1:40 AM, Michael S Collins wrote:
>
> It's all good. Now you have to pay it forward. :)
> -MC
>
> Sent from my iPhone
>
> On May 25, 2010, at 9:34 PM, RR <ranjtech at gmail.com> wrote:
>
> Michael,
>
> Thank you SO SO much for the help. Your regex work perfectly as desired. I
> had tried what you suggested earlier but I think I might've made a mistake
> somewhere because I wasn't getting the right results so I resorted to doing
> the "|" between the prefixes to strip them out thinking maybe FS works by
> going if it begins + OR +1 OR 011 then remove them but I guess it doesn't as
> when "\" appears it uses / matches against only the first one of the those
> as opposed to all of those.
>
> Thanks again and sorry for wasting your time ;)
>
> Cheers
> RR
>
> On Tue, May 25, 2010 at 9:19 PM, Michael Collins < <msc at freeswitch.org>
> msc at freeswitch.org> wrote:
>
>>
>>
>> On Tue, May 25, 2010 at 5:44 PM, RR < <ranjtech at gmail.com>
>> ranjtech at gmail.com> wrote:
>>
>>> Michael, haha, yeah they indeed are. That's why I'm routing based on $2,
>>> but I still see the 1 and/or the 011 going through to the "bridge"
>>> application. Why??
>>>
>> Because your regex is wrong. :) It took me a while to figure it out. I'm
>> surprised it worked at all. All the stuff you have inside the first set of
>> parens is not behaving the way you think it should be. If I read your
>> intentions correctly you're trying to strip off leading:
>> +
>> OR
>> +1
>> OR
>> 1
>>
>> In the first regex. Correct? If ANI is NANPA-ish then try this in your
>> first regex:
>> ^\+?1?([2-9]\d+).*$
>>
>> That should strip off leading + and/or 1 and capture just the 10-digit
>> phone number in $1. (Be sure to use $1 and not $2, unless you had your heart
>> set on using $2 in which case wrap the first part of the regex in parens)
>>
>> The other regex is also tricky. I assume you are trying to strip off the
>> same as above as well as 011? Try this:
>> ^\+?1?(011)?([2-9]\d+).*$
>>
>> Again, if the phone number in question is NANPA then $2 should contain
>> just the 10 digits you want. Play around with that and let us know what
>> happens. Also, don't forget what I said about using regex from the fs_cli.
>> You can test all this stuff yourself. :)
>>
>> -MC
>>
>>
>>
>>
>>>
>>> On Tue, May 25, 2010 at 8:34 PM, Michael Collins < <msc at freeswitch.org>
>>> msc at freeswitch.org> wrote:
>>>
>>>>
>>>>
>>>> On Tue, May 25, 2010 at 5:27 PM, RR < <ranjtech at gmail.com>
>>>> ranjtech at gmail.com> wrote:
>>>>
>>>>> Ok, so I take that back. This seems to only work when the dialplan has
>>>>> a specific ANI and DNIS / destination_number / sip_to_user defined. If this
>>>>> is more general
>>>>>
>>>>> like
>>>>>
>>>>> <include>
>>>>>   <extension name="public_did">
>>>>>     <condition field="ani" expression="^(\+?|\+1?|1?)(\d+).*$"
>>>>> break="never">
>>>>>         <action application="set"
>>>>> data="effective_caller_id_number=$2"/>
>>>>>         <action application="set" data="effective_caller_id_name=$2"/>
>>>>>     </condition>
>>>>>     <condition field="${sip_to_user}"
>>>>> expression="^(\+1?|\+|1?|011?)(\d+).*$" break="never">
>>>>>       <action application="set" data="continue_on_fail=false"/>
>>>>>       <action application="set" data="hangup_after_bridge=true"/>
>>>>>       <action application="set" data="domain_name=$${domain}"/>
>>>>>       <action application="set" data="bypass_media=true"/>
>>>>>       <action application="limit_hash" data="in cc_blades 4200
>>>>> !USER_BUSY"/>
>>>>>       <action application="bridge"
>>>>> data="{sip_invite_domain=${sip_from_host}}sofia/gateway/${distributor(cc_blades)}/$2"/>
>>>>>     </condition>
>>>>>   </extension>
>>>>> </include>
>>>>>
>>>>> then even though the expression/conditions seem to match, none of the
>>>>> digits are being stripped off. Shouldn't this be stripping off digits??
>>>>>
>>>>> Here's the debug output:
>>>>>
>>>>> Dialplan: sofia/external/16469NNNNNN Regex (PASS) [public_did]
>>>>> ani(16469NNNNNN;phone-context=+1) =~ /^(\+?|\+1?|1?)(\d+).*$/ break=never
>>>>> Dialplan: sofia/external/16469NNNNNN Action
>>>>> set(effective_caller_id_number=16469NNNNNN)
>>>>> Dialplan: sofia/external/16469NNNNNN Action
>>>>> set(effective_caller_id_name=16469NNNNNN)
>>>>> Dialplan: sofia/external/16469NNNNNN Regex (PASS) [public_did]
>>>>> ${sip_to_user}(011390NNNNNNNNNN;phone-context=+39) =~
>>>>> /^(\+1?|\+|1?|011?)(\d+).*$/ break=never
>>>>> Dialplan: sofia/external/16469NNNNNN Action set(continue_on_fail=false)
>>>>> Dialplan: sofia/external/16469NNNNNN Action
>>>>> set(hangup_after_bridge=true)
>>>>> Dialplan: sofia/external/16469NNNNNN Action
>>>>> set(domain_name=208.72.186.166)
>>>>> Dialplan: sofia/external/16469NNNNNN Action set(bypass_media=true)
>>>>> Dialplan: sofia/external/16469NNNNNN Action limit_hash(in cc_blades
>>>>> 4200 !USER_BUSY)
>>>>> Dialplan: sofia/external/16469NNNNNN Action
>>>>> bridge({sip_invite_domain=${sip_from_host}}sofia/gateway/${distributor(cc_blades)}/011390NNNNNNNNNN)
>>>>>
>>>>> why're the '1' in the ANI and '011' in the DNIS/sip_to_user being
>>>>> stripped off???
>>>>>
>>>>
>>>> Regex 101 :)
>>>>
>>>> The 1 or the 011 are in $1
>>>> -MC
>>>>
>>>>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100527/6b8d5c94/attachment-0001.html 


More information about the FreeSWITCH-users mailing list