Then you just limit the access on your external profile - by IP addresses or sip header fields. On 12 Oct 2015 13:48, "Michael Nielsen" <mic.niel84@gmail.com> wrote:
My reason for this kind of issue is that I have a case where users are charged for incoming calls...
So I want to make sure, that ONLY registrered users and my SIP gateway can make calls with our FreeSWITCH.
On Mon, Oct 12, 2015 at 1:18 PM, Michael Nielsen <mic.niel84@gmail.com> wrote:
I see that scenario make sense. But what if I only want to have registered users call each other?
I've tried with external_auth_calls=true in vars.xml, but that still allow completely external parties to call me...
On Thu, Oct 8, 2015 at 9:44 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
actually typically you don't want to limit your inbound calls.
For example, I get a Twilio PSTN number 1555123456, and configure twilio to send the calls to sip.example.com:5080. So, FreeSWITCH will receive the calls in public context.
Now, what I can do is give my SIP URI (1555123456@sip.example.com:5080) to third parties -- for example, register it at some ENUM directories. Or maybe my overseas partner configures their PBX to send calls to me directly via Internet, instead of sending it to their local PSTN.
So, what you need to make sure is that you only accept calls to your own numbers in public context. If you receive an unauthenticated call for some arbitrary destination number, it should be rejected (you don't really want to send it to PSTN, do you?).
If there's only a small quantity of PSTN numbers landing on your FreeSWITCH, you can simply configure a sequence of condition statements in the public context. If your setup is bigger, there are many ways to look up the number in some database and make a decision where to route it. One of the simplest ways is to have your directory users, one per DID, and use "user_exists" call to check if this is our number.
I don't see much of a reason in sending inbound calls to the internal profile (port 5060) and making an exclusion ACL to disable the authentication. It only makes things complex and it doesn't add security.
On Wed, Oct 7, 2015 at 5:15 PM, Gonzalo Gasca Meza <gascagonzalo@gmail.com> wrote:
I have a SIP Provider which has 4 IP addresses in US. They send SIP calls from any of those 4 IPs to my Freeswitch. **They do not require authentication, nor SIP Trunk registration, just purely send a SIP INVITE**
Incoming calls work fine except that I want to assign a context when I receive an incoming call from this ITSP at gateway level. Gateway xml file is configured under external folder. (../conf/sip_profiles/external/)
I can see in packet capture and in freeswitch.log call comes from correct ip and port, but is always routed to context default. Hence I need to configure something there. Is it possible to define context at gateway level?
Console trace: http://pastebin.com/NzzLAK8U Freeswitch trace http://pastebin.com/YUYVLfyY
I defined my 4 SIP Gateways (status up) as follows: (1 for each IP address)
<gateway name="itsp-inbound-us1">
<param name="auth-calls" value="false"/>
<param name="proxy" value="54.172.60.0"/>
<param name="register" value="false"/>
<param name="context" value="itsp"/>
<param name="username" value="not-required"/>
<param name="password" value="not-required"/>
<param name="from-user" value="not-required"/>
<param name="expire-seconds" value="600"/>
<param name="extension" value="1000"/>
</gateway>
sofia profile external gwlist
itsp-inbound-us4 itsp-inbound-us3 itsp-inbound-us2 itsp-inbound-us1
sofia status gateway itsp-inbound-us1
Name itsp-inbound-us1
Profile external
Scheme Digest
Realm 54.172.60.0
Username not-required
Password yes
From <sip:not-required@54.172.60.0>
Contact <sip:gw+itsp-inbound-us1@52.2.15.172:5060 ;transport=udp;gw=twilio-inbound-us1>
Exten 1000
To sip:not-required@54.172.60.0
Proxy sip:54.172.60.0
Context itsp
Expires 600
Freq 600
Ping 0
PingFreq 0
PingTime 0.00
PingState 0/0/0
State NOREG
Status UP
Uptime 536s
CallsIN 0
CallsOUT 0
FailedCallsIN 0
FailedCallsOUT 0
=================================================================================================
Any suggestion?
_________________________________________________________________________
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
_________________________________________________________________________ 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