[Freeswitch-users] prevent internal extensions from getting calls from outside

Juan Pablo L. jpablolorenzetti at hotmail.com
Mon Sep 3 18:30:08 MSD 2012


i followed your instructions and this is exactly what we needed,
thank you very much.


________________________________
> Date: Fri, 31 Aug 2012 22:19:27 -0700 
> From: msc at freeswitch.org 
> To: freeswitch-users at lists.freeswitch.org 
> Subject: Re: [Freeswitch-users] prevent internal extensions from  
> getting calls from outside 
>  
> On 8/31/2012 9:50 PM, Juan Pablo L. wrote: 
> Hi, yes we have a block of DIDs, externally you would dial 2802002 and  
> the gateway will send to the PBX 2002 which is the extension number.  
> Then the PBX should decide if 2002 is allowed to get the call or it  
> should present an IVR with an error message. Thanks. 
>  
> Try something like this: 
> Add the variable in the user XML configs like you did. In this example  
> we'll use: 
> <variable name="allow_incoming_calls" value="false"/> 
>  
> I'm not sure how you route the incoming DID block, but you could do  
> something like this in your public.xml file or in a file in  
> conf/dialplan/public/: 
> <extension name="Routing Inbound DIDs"> 
>    <condition field="destination_number" expression="^(280(20\d\d))$"> 
>      <action application="set_user" data="$2@${domain}"/> 
>      <action application="transfer" data="$1 XML default"/> 
>    </condition> 
> </extension> 
>  
> Then near the top of default.xml you could do something like this: 
> <extension name="Handle inbound exceptions"> 
>    <condition field="${allow_incoming_calls}" expression="^false$"/> 
>    <condition field="destination_number" expression="^280(20\d\d)$"> 
>      <action application="log" data="INFO Call to extension $1 being  
> routed to IVR"/> 
>      <action application="ivr" data="my_ivr"/> 
>    </condition> 
> </extension> 
>  
> Naturally you'll need to build "my_ivr" or otherwise do something with  
> the call. Standard disclaimer applies: I dropped this in off the top of  
> my head so be sure to tinker with it if it doesn't work the first time.  
> :) 
>  
> -MC 
> -----Original Message----- 
>  
> From: Michael Collins 
> Sent: 1 Sep 2012 03:41:46 GMT 
> To: FreeSWITCH Users Help 
> Subject: Re: [Freeswitch-users] prevent internal extensions from  
> getting calls from outside 
>  
> How is the caller getting to the extension in the first place? Do you  
> have a block of DIDs or is the caller dialing an ext at an auto attn? 
> -MC 
>  
> On Friday, August 31, 2012, Juan Pablo L.  
> <jpablolorenzetti at hotmail.com<mailto:jpablolorenzetti at hotmail.com>>  
> wrote: 
>  > Hi, i have a gateway that allows us to call outside and allows calls  
> to reach the extensions from outside, 
>  > but i have a bunch of extensions that we dont want to be able to  
> receive calls from outside. 
>  > We have a block of numbers, if any of those numbers is dialed from  
> the PSTN or any external network 
>  > the call will be routed, through the external gateway, to the PBX so  
> it is up to the PBX to decide 
>  > if the call should reach the extension or not. there are some  
> restrictions .. i can not have different number segments 
>  > for the extensions, they all are in the same segment, a given  
> extension could not be allowed to be reached from outside 
>  > at this time but it may be reachable in a latter time (due to change  
> in the user status in the company), etc ... 
>  > i tried to put a variable in the directory for a user but when the  
> call arrives at the PBX and the PBX is routing 
>  > that variable is not available yet and i m having trouble figuring  
> out when that variable is available before bridging the call 
>  > so i can use it as a condition to route the call. 
>  > 
>  > any hint will on how to deal with will help. thanks! 
>  > _________________________________________________________________________ 
>  > Professional FreeSWITCH Consulting Services: 
>  > consulting at freeswitch.org<mailto:consulting at freeswitch.org> 
>  > http://www.freeswitchsolutions.com 
>  > 
>  >  
>  >  
>  > 
>  > Official FreeSWITCH Sites 
>  > http://www.freeswitch.org 
>  > http://wiki.freeswitch.org 
>  > http://www.cluecon.com 
>  > 
>  > FreeSWITCH-users mailing list 
>  >  
> FreeSWITCH-users at lists.freeswitch.org<mailto: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 
>  > 
>  
> --  
> Michael S Collins 
> Twitter: @mercutioviz 
> http://www.FreeSWITCH.org 
> http://www.ClueCon.com 
> http://www.OSTAG.org 
>  
>  
>  
>  
>  
> _________________________________________________________________________ 
> Professional FreeSWITCH Consulting Services: 
> consulting at freeswitch.org<mailto:consulting at freeswitch.org> 
> http://www.freeswitchsolutions.com 
>  
>  
>  
>  
> Official FreeSWITCH Sites 
> http://www.freeswitch.org 
> http://wiki.freeswitch.org 
> http://www.cluecon.com 
>  
> FreeSWITCH-users mailing list 
> FreeSWITCH-users at lists.freeswitch.org<mailto: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 FreeSWITCH-powered IP PBX: The  
> CudaTel Communication Server  Official FreeSWITCH  
> Sites http://www.freeswitch.org http://wiki.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 		 	   		  


Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users mailing list