Skip to main content

Amazon EC2

About​

This page covers how to install and configure FreeSWITCH on Amazon EC2.

Many FreeSWITCH installations have been successfully deployed on virtual environments. Because virtual hosts vary widely in performance and services that they offer and because your application will have its own specific needs, you must test your specific combination of virtual host and FreeSWITCH application. For example, a large video conference server will have different requirements than a voice transit switch. Ask the FreeSWITCH community for guidance and experiences to help you choose.

Click to expand Table of Contents

Opening Firewall Ports​

Create Security Group via EC2 Management Console​

Create a Security Group with the following ports. The ports listed in this snapshot are for Verto Communicator only... Add additional ports for SIP (not listed here).

Assign new Security group to instance.​

or, do it via aws cli​

SIP​

ec2-authorize default -P udp -p 5060

RTP​

ec2-authorize default -P udp -p 16384-32768

The RTP port range given should match your configuration in switch.conf.xml.

Additional EC2 NAT Notes​

For SIP, setup a security group with the following ports enabled (easiest to do with Elasticfox):

udp     16384:32768
udp     4569
udp     5060
tcp     5060
udp     5080
tcp     5080
tcp     8000
udp     8000

Make sure you make the security group, and apply it before you boot the instance. After this, the quick and dirty install guide worked just fine for me. You'll just need to tweak the default dialplan to your needs.

You may also need to make some of the following changes, particularly the external SIP and RTP IPs. The URLs in the commands below retrieves the external IP address of an instance (either the one mapped automatically at instance creation or the Elastic IP attached to the instance.)

conf/vars.xml

<X-PRE-PROCESS cmd="exec-set" data="bind_server_ip=curl -s http://instance-data/latest/meta-data/public-ipv4"/>
<X-PRE-PROCESS cmd="exec-set" data="external_rtp_ip=curl -s http://instance-data/latest/meta-data/public-ipv4"/>
<X-PRE-PROCESS cmd="exec-set" data="external_sip_ip=curl -s http://instance-data/latest/meta-data/public-ipv4"/>

The alternative to the above commands is to hard code the external IP addresses. However, this will require you to customize the vars.xml file for each instance (i.e. each external IP address) to which it is deployed. It will also have to be changed if you map/unmap an Elastic IP to the instance.

<X-PRE-PROCESS cmd="set" data="bind_server_ip=[AWS EIP]"/>
<X-PRE-PROCESS cmd="set" data="external_rtp_ip=[AWS EIP]"/>
<X-PRE-PROCESS cmd="set" data="external_sip_ip=[AWS EIP]"/>

conf/autoload_configs/verto.conf.xml

<param name="ext-rtp-ip" data="[AWS EIP]">

conf/sip_profiles/internal.xml

<param name="aggressive-nat-detection" value="true"/>
<param name="multiple-registrations" value="true"/>
<param name="ext-rtp-ip" value="$${external_rtp_ip}"/>
<param name="ext-sip-ip" value="$${external_sip_ip}"/>
<param name="NDLB-received-in-nat-reg-contact" value="true"/>
<param name="NDLB-force-rport" value="true"/>
<param name="NDLB-broken-auth-hash" value="true"/>
<param name="enable-timer" value="false"/>
<param name="auth-calls" value="true"/>

conf/sip_profiles/external.xml

<param name="aggressive-nat-detection" value="true"/>
<param name="ext-rtp-ip" value="$${external_rtp_ip}"/>
<param name="ext-sip-ip" value="$${external_sip_ip}"/>
<param name="NDLB-force-rport" value="true"/>

conf/autoload/switch.conf.xml

<param name="rtp-start-port" value="16384"/>
<param name="rtp-end-port" value="32768"/>

Sofia External IP Config​

You shouldn't have to make any changes to the Sofia profile. The FreeSWITCH Auto NAT feature will take care of this automatically. However, if you want to do this manually, edit the sip_profiles/internal.xml file and replace auto-nat with the external IP address in the ext-rtp-ip and ext-sip-ip parameters.

FAQ​

Q: What distro should I use?​

Debian 10 Buster is the recommended distribution to use for FreeSWITCH™ 1.10 and later. See Installation for more details.

Q: Can I run this as a production switch?​

A small instance is not recommended for running FreeSWITCH in production, however you should be happy with a High CPU Medium instance.

Experiences:

  • From Cfurmori in May 2009: I wouldn't recommend running FreeSWITCH in production on Amazon EC2. I purchased a 1 year instance of a small server setup and used a base CentOS 5.3 image 32-bit x86. Built FreeSWITCH from the latest snapshot and it worked great for dev and testing purposes but the call quality was pretty bad at times. I spent a fair amount of time tuning / testing / watching resource utilizations running a 4 person conference and I would see an average of 0.5 to 1.0 second audio delay. I tried with direct SIP phone registrations and through a SIP trunk provider, same results. EC2 is a great dev/test platform but I would say your best to run a realtime voice application on a physical server. You can virtualize voice systems but they need to be designed and engineered by someone that knows what they are doing.
  • A mailing list user said in March 2010: "We run FreeSWITCH on AWS' EC2. A medium EC2 instance is happily supporting 100 Polycom users, conference bridges etc. Been running for over a year. We also use FlowRoute as our PSTN->SIP Interface, and also Skype Business SIP. Our users are scattered across the globe - so having the box sitting on AWS' network infrastructure is key to avoiding issues with latency, jitter, packet loss (i.e. I don't think we could afford the connectivity AWS gives us if we had to provision this in-house)."

Attachments:​

image2018-2-16 8:44:48.png (image/png)
image2018-2-16 8:50:31.png (image/png)
image2018-2-16 9:22:11.png (image/png)
aws_inbound_rules.png (image/png)

Comments:​

why is multiple-registrations required? Posted by at Jun 17, 2014 14:52
Why not? In internal context all users are verified. You can comment this. Posted by denis at Feb 02, 2015 05:13