Deployment questions: Freeswitch or Freeswitch with a SIP proxy server
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@remote will result in the call being directed to 1001@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@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
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@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@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.
On 25.08.2010 18:42, Tim St. Pierre wrote:
"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@our.domain gets sent here, and the call is processed. Yeah, currently I have the same setup for DNS, just the profile is called 'external' like in the default configuration.
"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. So basically it works mostly like the default 'internal' profile, right? 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. No ACL checking? Because the default internal profile just rejects everything that arrives to it and is not authenticated.
-- Kamigishi Rei KREI-RIPE
participants (2)
-
Kamigishi Rei
-
Tim St. Pierre