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

[Kamigishi Rei]

  Hello,

I need to set up a relatively small (up to, probably, 5000 users at 
maximum) SIP service; however I'm not sure if what I need can be 
implemented by using Freeswitch, so I decided to consult this mailing list.

First, the essential part: local calls within the SIP realm; easy to get 
implemented and basically works out of the box with some scripts to 
export data from our billing database and to convert that data into XML. 
The second task, implementing a PSTN gateway, looks pretty 
straightforward, too.

However, there are a few questions about something else: external SIP 
servers/operators, and DNS/ports setup.

Basically, I can receive inbound calls from other SIP operators to my 
public extensions out of the box, without setting up any gateways and 
such; that behaviour is welcome. However, the invite domain presented 
gets changed to FreeSwitch's IPv4 address before showing up on the 
softphone. Is overriding it with 
"{sip_invite_domain=${sip_from_host}}sofia/internal/$1%$${domain}" in a 
bridge application considered bad practice?

Placing outbound calls to other SIP operators: this "sort of" works if I 
uncomment

<!-- If sip_req_host is not a local domain then this has to be an 
external sip uri -->
<!--
<extension name="external_sip_uri" continue="true">
<condition field="source" expression="mod_sofia"/>
<condition field="${outside_call}" expression="^$"/>
<condition field="${domain_exists(${sip_req_host})}" expression="true">
<anti-action application="bridge" 
data="sofia/${use_profile}/${sip_to_uri}"/>
</condition>
</extension>
     -->

in dialplan/default.xml.

However, this is a very weird and - to me - extremely crude solution as, 
first, it's a fallback rule (thus we can't call a remote extension that 
also exists in our system - f.ex. calling 1001 at remote will result in the 
call being directed to 1001 at local), and second, 
${domain_exists(${sip_req_host})} is a really lousy check and doesn't 
account for DNS aliases, IP addresses, etc. thus resulting in possible 
fallback to a direct call instead of a dialplan route if the 
sip_invite_domain wasn't set properly and we got a call back.
It's even more confusing if we use DNS NAPTR and SRV records.

Currently, I have the following in my dialplan:

<extension name="external_domain_outbound_calls" continue="true">
<condition field="source" expression="mod_sofia"/>
<condition field="${outside_call}" expression="^$"/>
<condition field="${sip_to_host}" 
expression="^((${domain}|sip.${domain})|${local_ip_v4}|)$">
<anti-action application="bridge" 
data="{sip_invite_domain=$${domain}}sofia/${use_profile}/${sip_to_uri}"/>
</condition>
</extension>

Does it seem acceptable or is that bad practice as well?

Is placing outbound calls to external SIP URIs considered bad practice 
overall when using Freeswitch? From what I've gathered @ the irc 
channel, "Freeswitch is not a proxy", so should I instead use something 
like OpenSIPS for such tasks?

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.

If I specify my Freeswitch server as the SIP proxy, the aforementioned 
external_domain_outbound_calls extension takes care of it by replacing 
sip_invite_domain in the headers. But since "Freeswitch is not a proxy", 
I guess there should be some other solution instead of having to place 
calls to external URIs via Freeswitch?

Overall, if accepting unauthenticated inbound calls on the internal 
profile is fine and they still go into public context, I guess it's fine 
to have the DNS point at the internal profile? (Since gateways can 
connect to the external profile's port explicitly.)

Thanks in advance.

-- 
Kamigishi Rei
KREI-RIPE