Incoming call-limit can be controlled in FreeSWITCH from user directory for example:

<document type=”freeswitch/xml”>
  <section name=”directory”>
    <domain name=”192.168.0.2″>
      <user id=”some_user”>
        <params>
          <param name=”password” value=”some_password”/>
        </params>
        <variables>
                       <variable name=”accountcode” value=”315″/>
                       <variable name=”user_context” value=”default”/>
                       <variable name=”vm_extension” value=”315″/>
                       <variable name=”max_calls” value=”1″/>
          </variables>
      </user>
    </domain>
  </section>
</document>

The following channel variables are set when mod_limit is called.

• “limit_realm”
• “limit_id”
• “limit_max”

These channel variables are used at hang up to remove the record. More specifically, the delete is limited by uuid, hostname, realm and id.

<extension name=”Outbound Limit”>
        <condition field=”destination_number” expression=”^00″/>
         <action application=”limit” data=”$${domain} gw_PROVIDER PROVIDER_CHANNEL_LIMIT nextgw1″/>
                <action application=”bridge” data=”sofia/gateway/PROVIDER/1$1″/>
                <action application=”transfer” data=”nextgw1″/>
        </condition>
</extension>

The following example shows how a DID can bridge to multiple extensions or gateways sequentially in a hunt pattern. In Asterisk, this feature is called FollowMe. If none of the bridges are successful the caller is sent to voicemail for example.

<extension name=”12531234567″>
  <condition field=”destination_number” expression=”12531234567″>
   <action application=”set” data=”hangup_after_bridge=true”/>
   <action application=”set” data=”continue_on_fail=true”/>
   <action application=”set” data=”ignore_early_media=true”/>
   <action application=”set” data=”call_timeout=10″/>
   <action application=”bridge” data=”sofia/$${domain}/1001″/>
     <action application=”set” data=”call_timeout=13″/>
   <action application=”bridge” data=”sofia/gateway/isoftswitch/123456789″ />
   <!– No answer, transfer to voicemail –>
   <action application=”answer”/>
   <action application=”sleep” data=”1000″/>
   <action application=”voicemail” data=”default $${domain} 1001″/>
  </condition>
</extension>

Forked dial is when you want to attempt to ring 2 destinations at the same time. Freeswitch will attempt to call both bridge options simultaneously. The first bridge leg that replies with a 183 (session progress) message will win the call, and the other bridge leg is dropped. This only will work if you enable inbound-late-negotiation in the profile this recipe is executing under ( not in the bridged-to profile ).

an example is:

 <extension name="dialoutpstn">
     <condition field="destination_number" expression="^((00).*)$">
       <action application="set" data="hangup_after_bridge=true"/>
       <action application="set" data="ignore_early_media=true"/>
       <action application="bridge" data="sofia/gateway/gatewayA/$1@1.2.3.4,sofia/gateway/gatewayB/$1@4.5.6.7"/>
       </condition>
 </extension>

Here is the link:

http://www.research.att.com/~ttsweb/tts/demo.php

The following link contains list of TCP and UDP ports:

http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

Add the following to default.xml (in prefix/conf/dialplan) for 11 digit dialing (US) via your newly created gateway configuration above. Remember, the default configuration provided by FreeSWITCH does not include a diaplan rule for outbound calls via the gateway you’ve defined. You will need to add something similar to the following.

<!– Dial any 10 digit number (1223334444) or 1+10 number (11223334444) here –>
   <extension name=”Long Distance – isoftswitch”>
    <condition field=”destination_number” expression=”^(1{0,1}\d{10})$”>
      <action application=”set” data=”effective_caller_id_number=11223334444″/>
      <!– If your provider does not provide ringback (180 or 183) you may simulate
        ringback by uncommenting the following line. –>
      <!– action application=”ringback” /–>
      <action application=”bridge” data=”sofia/gateway/isoftswitch/$1″/>
     </condition>
   </extension>

FreeSWITCH supports the encryption of SIP signaling traffic via SSL and/or TLS. The convention is to run the SIPS on port 5061. More complex configurations are possible, however they will not be covered in this documentation.

You will need the following in order to compile FreeSWITCH with TLS encryption support:

• OpenSSL-Dev package installed.

If you do not have the OpenSSL-Dev package installed the problem is the sip_profile that contains the encryption configuration directives specified below in Step 2 will fail to start. If you’ve compiled FreeSWITCH without this package installed, there will be no support for encryption and you will need to re-compile it after you install the OpenSSL-Dev package.

For debian do aptitude install libssl and then compile.

Step 1 – Generate the CA Certificate

To use TLS you need at least two certificates: the root certificate (CA) and a certificate for every server. There is a script at /{prefix}/freeswitch/bin/gentls_cert or within the source tarball {tarball}/scripts/gentls_cert that helps generate these files. With

   ./gentls_cert setup

You can create a new root certificate that will be stored at /{prefix}/freeswitch/conf/ssl/cafile.pem. It will be used to digitally sign all server certificates and must normally be installed also on every phone.

Step 2 – Generate the Server Certificate

The command:

   ./gentls_cert create -cn freeswitch.org -alt DNS:freeswitch.org

creates the server certificate at /{prefix}/freeswitch/conf/ssl/agent.pem. This file contains the certificate and the private key. It should contain the domain name in the common and alternate name.

To set up new CA and create new certificate under Windows go here.

In order for the new certificate to take effect only way for FS to use it to restart FS.

Step 3 – Sofia Profile Configuration

On your vars.xml.

ATTENTION: TLS is disabled by default, set internal_ssl_enable and/or external_ssl_enable to “true” to enable.

Step 4 – Securing the RTP Channels (optional)

Calls that originate from the phone have sip_secure_media set if tls is setup. Check the global extension. There is a section commented that out will require SRTP on the outbound leg if the inbound leg is encrypted. Enabling this will be problematic with most ITSPs since they do not support tls.

For calls that originate from FreeSWITCH (or routed through) and are terminated on the user/ endpoint (eg: calls to a phone), the following change will enable srtp if the endpoint registered with tls. Note that it is a valid configuration to register with tls but not require srtp. This disables that valid configuration option for user/ endpoints. It would also require further refinement to support ZRTP on user/ endpoints that connect with tls. In that case, a better approach would be to set something on the user’s directory entry that specifies which RTP encryption to support. (in other words, there is a reason this is not the default setting)

Edit conf/directory/default.xml and change the dial-string param to:

 <param name="dial-string" value="{sip_secure_media=${regex(${sofia_contact(${dialed_user}@${dialed_domain})}|transport=tls)},presence_id=${dialed_user}@${dialed_domain}}${sofia_contact(${dialed_user}@${dialed_domain})}" />

Why it’s a good idea

In the SIP Encryption Primer above we discussed why encrypting the RTP data may be a good idea. This is largely done in the Dialplan and has it’s own page dedicated to it’s functionality.

SRTP by itself without TLS is not secure since the keys are exchanged between the two endpoints in the clear over SIP, which is insecure without TLS or SSL.

See Secure RTP page of the FreeSWITCH Wiki for how to deploy SRTP.

For completely secure connection (signaling + media) use TLS + SRTP. TLS without SRTP secures SIP. SRTP without TLS does not really secure RTP !

  <!--
      SIP and TLS settings.
  -->
  <X-PRE-PROCESS cmd="set" data="sip_tls_version=tlsv1"/>

  <!-- Internal SIP Profile -->
  <X-PRE-PROCESS cmd="set" data="internal_auth_calls=true"/>
  <X-PRE-PROCESS cmd="set" data="internal_sip_port=5060"/>
  <X-PRE-PROCESS cmd="set" data="internal_tls_port=5061"/>
  <X-PRE-PROCESS cmd="set" data="internal_ssl_enable=false"/>
  <X-PRE-PROCESS cmd="set" data="internal_ssl_dir=$${base_dir}/conf/ssl"/>

  <!-- External SIP Profile -->
  <X-PRE-PROCESS cmd="set" data="external_auth_calls=false"/>
  <X-PRE-PROCESS cmd="set" data="external_sip_port=5080"/>
  <X-PRE-PROCESS cmd="set" data="external_tls_port=5081"/>
  <X-PRE-PROCESS cmd="set" data="external_ssl_enable=false"/>
  <X-PRE-PROCESS cmd="set" data="external_ssl_dir=$${base_dir}/conf/ssl"/>

This configuration is only for SIP TLS. SRTP hasn’t been tested.

• To import a root certificate into the device, it must be in DER encoded format. To setup a certificate that is create using gentls_cert script use the following command

openssl x509 -in /usr/local/freeswitch/conf/ssl/CA/cacert.pem -out /usr/local/freeswitch/conf/ssl/CA/cacert.cer -outform DER

• Copy the new cacert.cer to the device, and run it in file manager. This will prompt you the save it as a trusted certificate. Do this and select all trust levels during installation.
• Setup your SIP Profile using “sips:” instead of “sip:” in Public Username, Proxy Server Address and Register Server Address, and set the appropriate port for your FreeSWITCH installation.

ATTENTION!!! Set the “Transport type” to “AUTO” or it will not work!

The rlm_acct_unique module creates a unique accounting session Id.

Many NAS vendors have their equipment supply an Acct-Session-Id attribute which is not unique over reboots. This makes accounting difficult, as there will be many independent sessions with the same Acct-Session-Id attribute. This module uses the Acct-Session-Id attribute, along with other attributes in the request, to create a more unique session ID, called Acct-Unique-Session-Id.

The main configuration items to be aware of are:

keyA list of the attributes used in calculating an MD5 hash which is used as the value for the unique session id.

Configuration

modules { …
acct_unique {

key = “User-Name, Acct-Session-Id, NAS-IP-Address, NAS-Port”

}
…
}
…
preacct { …
acct_unique …
}After generating the MD5 hash, the module adds it to the accounting request packet received from the client. It will look something like this in your detail file:

Acct-Unique-Session-Id = “c66ef57e480b9d26″

NOTE: Any attribute you specify that is not found in the ‘dictionary’ file will cause the server to fail and exit with an error.NOTE: If you want the Acct-Unique-Session-Id of the Start and the Stop packet of a particular session to match, you must use values for the key that will stay the same for the Start and Stop. The above example is a good start. Adding ‘Acct-Session-Time’, for example, would cause a mismatch because that value is not the same on the Start and Stop accounting packets.