Auto Nat
autonat and external ip
If you know your external ip, you can set it on your sofia profile and also instruct FreeSWITCH™ to set it when building the SDP:
< param name = "ext-sip-ip" value = "autonat:${external_sip_ip}" />
If you want to use the same profile to talk with things inside and outside your network you need to instruct FreeSWITCH™ when it should use the local IP and the external IP. The autonat: prefix toggles on the usage of the local-network-acl, if you prefix the IP like that it will activate the dynamic ability to tell when it should use ext-rtp-ip vs rtp-ip based on the acl match.
Sofia Configuration Files
ext-rtp-ip
This is the IP behind which FreeSWITCH is seen from the Internet, so if FreeSWITCH is behind NAT, this is basically the public IP that should be used for RTP.
| ext-rtp-ip value |
Description |
Example |
| $${variable} |
Any variable from vars.xml |
<param name="ext-rtp-ip" value="$${external_rtp_ip}"/> |
| w.x.y.z |
Specific numeric IP address |
<param name="ext-rtp-ip" value="1.2.3.4"/> |
| autonat:w.x.y.z |
Used for LAN and WAN to avoid errors in the SIP CONTACT sent to LAN devices |
<param name="ext-rtp-ip" value="autonat:1.2.3.4"/> |
| auto |
Guessed IP (guessed by looking in the IP routing table which interface is the default route) |
<param name="ext-rtp-ip" value="auto"/> |
| auto-nat |
FS uses uPNP or NAT-PMP to discover the public IP address it should use |
<param name="ext-rtp-ip" value="auto-nat"/> |
| stun:DNS name or IP address of STUN server |
FS uses the STUN server of your choice to discover the public IP address |
<param name="ext-rtp-ip" value="stun:stun.freeswitch.org"/> |
| host:DNS name |
FS resolves the DNS name as the public IP address, so you can use a dynamic DNS host |
<param name="ext-rtp-ip" value="host:mypublicIP.dyndns.org"/> |
params with the ‘ext–’ prefix cited above when populated with yet-to-be-resolved DNS strings (e.g. name="ext–sip–ip" value="stun:stun.freeswitch.org" or name="ext‑rtp–ip" value="host:mypublicIP.dyndns.org" ) are resolved to IP addresses once only at FreeSWITCH load time and remain constant thereafter. FS is blind to (unaware of) any subsequent changes in your environment’s IP address. Thus, these ext– vars may become functionally incompatible with the environment’s current IP addresses with unspecified results in call flow at the network layer. FS restart is required for FS to capture the now-current, working IP address(es).
NATing
apply-nat-acl
When receiving a REGISTER or INVITE, enable NAT mode automatically if IP address in Contact header matches an entry defined in the RFC 1918 access list. “acl” is a misnomer in this case because access will not be denied if the user’s contact IP doesn’t match.
<param name="apply-nat-acl" value="rfc1918"/>
Auth
These settings deal with authentication: requirements for identifying SIP endpoints to FreeSWITCH.
auth-calls
Users in the directory can have “auth-acl” parameters applied to them so as to restrict users access to a predefined ACL or a CIDR.
<param name="auth-calls" value="$${internal_auth_calls}"/>
Value can be “false” to disable authentication on this profile, meaning that when calls come in the profile will not send an auth challenge to the caller.
TLS
Please make sure to read SIP TLS before enabling certain features below as they may not behave as expected.
tls
TLS: disabled by default, set to “true” to enable
<param name="tls" value="$${internal_ssl_enable}"/>
tls-only
disabled by default, when enabled prevents sofia from listening on the unencrypted port for this connection. This can stop many generic brute force scripts and if all your clients connect over TLS then can help decrease the exposure of your FreeSWITCH server to the world.
<param name="tls-only" value="false"/>
tls-bind-params
additional bind parameters for TLS
<param name="tls-bind-params" value="transport=tls"/>
tls-sip-port
Port to listen on for TLS requests. (5061 will be used if unspecified)
<param name="tls-sip-port" value="$${internal_tls_port}"/>
tls-cert-dir
Location of the agent.pem and cafile.pem ssl certificates (needed for TLS server)
<param name="tls-cert-dir" value="$${internal_ssl_dir}"/>
tls-version
TLS version (“sslv2”, “sslv3”, “sslv23”, “tlsv1”, “tlsv1.1”, “tlsv1.2”). NOTE: Phones may not work with TLSv1
<param name="tls-version" value="$${sip_tls_version}"/>
When not set defaults to: “tlsv1,tlsv1.1,tlsv1.2”
tls-passphrase
If your agent.pem is protected by a passphrase stick the passphrase here to enable FreeSWITCH to decrypt the key.
<param name="tls-passphrase" value=""/>
tls-verify-date
If the client/server certificate should have the date on it validated to ensure it is not expired and is currently active.
<param name="tls-verify-date" value="true"/>
tls-verify-policy
This controls what, if any security checks are done against server/client certificates. Verification is generally checking certificates are valid against the cafile.pem. Set to ‘in’ to only verify incoming connections, ‘out’ to only verify outgoing connections, ‘all’ to verify all connections, also ‘subjects_in’, ‘subjects_out’ and ‘subjects_all’ for subject validation (subject validation for outgoing connections is against the hostname/ip connecting to). Multiple policies can be split with a ‘|’ pipe, for example ‘subjects_in|subjects_out’. Defaults to none.
<param name="tls-verify-policy" value="none"/>
tls-verify-depth
When certificate validation is enabled (tls-verify-policy) how deep should we try to verify a certificate up the chain again the cafile.pem file. By default only depth of 2.
<param name="tls-verify-depth" value="2"/>
tls-verify-in-subjects
If subject validation is enabled for incoming connections (tls-verify-policy set to ‘subjects_in’ or ‘subjects_all’) this is the list of subjects that are allowed (delimit with a ‘|’ pipe), note this only effects incoming connections for outgoing connections subjects are always checked against hostnames/ips.
<param name="tls-verify-in-subjects" value=""/>
nginxの