[Freeswitch-users] Deployment questions: Freeswitch or Freeswitch with a SIP proxy server

[Tim St. Pierre]

You don't have to use the profiles "as-is" if they don't suit.

Here's our solution.  Let me know if it might apply to your case:

"public" profile:
Listens on port 5080
Has it's own dialplan that can deliver a call to extensions, but doesn't allow calls to much else.
The dialplan is written with security in mind.
The DNS SRV record for our domain points to the public IP address for this profile, port 5080.
Anyone dialing EXTEN at our.domain gets sent here, and the call is processed.

"trunks" profile
Listens on port 5060 (that's what our trunking providers expect).
Has it's own dialplan that matches incoming calls to their respective DIDs using lua/mysql and
routes the call to the correct destination within our system.
An ACL authenticates our trunking peers based on IP address and blocks everyone else.
We can also assume that all calls coming in on this profile are billable (they come from the PSTN
via a carrier switch).  DNS isn't important to us on this profile, since our carriers map straight
to the switch IPs, but we could do something like trunks.our.domain for the SRV record

"internal" profile.
listens on port 5070 (and eventually 5071 when I get TLS working)
Is used for all the SIP endpoints, and authenticates them when they register.
This profile goes to our internal dialplan, that routes to extensions, features, pstn, etc.  We will
also setup external domain matching here.
All the phones register to pbx.our.domain which has an SRV record as well.
We aliased that domain name to the profile, so it's happy to register the phones with that domain
name.  All the phones use the same domain name to register.
If a call comes in on this profile for anything other than pbx.our.domain, we can match this in the
dialplan and send a call out on the "public" profile to whomever they want to call.

With Freeswitch, you can make as many profiles as you want, and you can configure them any way you
want.  It did take a bit of figuring to make everything work right with DNS though.  We wanted to
use SRV records for everything, so that we can load balance / fail over the entire network.  The
only problem that arises is with some endpoints that insist on using the A record.
You could swap the ports on your trunks and public profiles if your peers don't mind sending calls
to port 5080.  That would let you keep using the default port for public calls.

-Tim

> And about the DNS settings:
> 
> It is established that the internal profile serves authenticated 
> clients, and the external profile is for untrusted connections (gateways).
> I presume that to receive calls to my public extensions, I need the 
> remote SIP operators/servers/clients to be able to find my "public" SIP 
> port, which is 5080 in the default configuration. Therefore, I have the 
> IN SRV records for "mydomain.org" pointing at port 5080, external 
> profile. Or is it acceptable to receive external calls to public 
> extensions to the internal profile? (Clarification needed here; is 
> "external" profile supposed to be "for external gateways", or "for any 
> untrusted connections, including calls from non-gateways to our public 
> extensions". Also, is accepting calls from a non-authenticated SIP peer 
> to the public extensions, but on the internal profile's port, not 
> recommended?)
> 
> However because of that I have to use a DNS alias (or just the IP 
> address) in the clients' (f.ex. softphones) configuration; f.ex. 
> "sip.mydomain.org".
> This results in clients using "sip.mydomain.org" as their authentication 
> realm (which is understandable), and direct - non-proxied - outbound 
> calls appear as "ext at sip.mydomain.org" on the remote side. Which leads 
> to calls originating from the remote side based on their call history 
> arriving on port 5060, internal profile.