[Freeswitch-users] Freeswitch inbound logic match

[Michael Nielsen]

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 at 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 at 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 at 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 at 54.172.60.0>
> >
> > Contact
> > <sip:gw+itsp-inbound-us1 at 52.2.15.172:5060
> ;transport=udp;gw=twilio-inbound-us1>
> >
> > Exten   1000
> >
> > To      sip:not-required at 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20151012/a35e07c2/attachment-0001.html