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