This easy guide for sipxecs for admins covers basic steps from installing sipXecs to placing your first internal and external calls. If you want to get started quickly, get an idea whether sipXecs is for you, stage a demo to show off, or to just experience a modern communications system, this guide is for you.
Whether you are installing thousands of devices or just setting up a demo system, the sipXecs automated installation and configuration process and it’s graphical user interface make the process straightforward and easy. Let’s go!
Physical server: Dual or quad core CPU, 4 GB of RAM (minimum), 40 GB hard drive (minimum), and 1 network card. This machine’s hard drive will be wiped. Login to SIPfoundry.org and download the sipXecs ISO from the Download page.
Virtual machine: Clean VM from e.g. Google or Amazon. Avoid instances that have CPanel installed (such as VPS from Bluehost). Two compute cores, 2 to 4 GB RAM, 16 GB storage, excluding storage for voicemail.
Preferably use a separate routed network segment so that sipXecs can install and run its own DHCP server for phone auto-discovery and provisioning. If you cannot do that, no problem. You just have to manually configure sipXecs as the FTP server into each phone for it to download the configuration.
Desk phones: Polycom is the preferred phone but many other options exist
Softphones: Counterpath Bria is preferred but many other SIP softphones will work such as Counterpath X-Lite, Linphone, Jitsi
Mobile: Counterpath Bria smartphone and tablet app (iPhone and Android). Many other SIP mobile clients will work such as CSipSimple, SIP Phone, SIPdroid
An XMPP client on your laptop or smartphone / tablet. Consider some of the many free options including Adium, Jitsi, Trillian, yaxim
Either via a PSTN gateway (Audiocodes is the preferred brand) or with a SIP trunk. There are several ITSP’s that work
For SIP trunking or connectivity to devices connected via the Internet you will want a firewall / SBC. sipXecs includes a simple SBC (sipXbridge) that might be sufficient for a test setup. Also, sipXecs includes native NAT traversal for remote devices connected via NAT. Sangoma, Ingate, Audiocodes, or ACME Packet are all good choices for aprofessional SBC.
Boot from DVD and let the installation run (this will wipe out your hard drive!). You’ll need to know the following information:
Root password: this will be the Linux root password
Host name: fully qualified domain name (host.domain)
IP address: IP address for the host (use a fixed or reserved address)
Subnet mask: subnet mask as per your network segment
Default gateway: default gateway for above address/subnet
After the installation completes login with the root account you just configured. The sipxecs-setup script will start automatically.
Launch a fresh VM booting a minimal vanilla CentOS 6 / 64 bit image. Avoid virtual private servers or shared hosts that run CPanel (such as a VPS host from Bluehost or other hosters). Google Compute Cloud or Amazon EC2 are good choices.
Configure hostname, domain, and networking parameters as described for a physical server above.
Configure network? Answer ‘no’ if your network is configured already
First server? Answer ‘yes’
Host name? Enter desired hostname. ‘sipxecs’ is a possible choice.
Domain? Enter the desired domain, such as ‘example.com’
SIP Domain? Consider using an unused subdomain, such as ‘sip.example.com’. This will allow sipXecs to setup a DNS server for this domain without causing conflicts
SIP Realm? The SIP realm or URL you want to use for SIP addresses
To here this install should take no more than 15 to 20 minutes.
Point your browser at the IP address you assigned during installation. Acknowledge the certificate warning the browser shows you. You are now redirected to the login screen.
Enter the password you want to assign to the ‘superadmin’ user. Now login as superadmin. You are now looking at the administration portal’s home page.
By default after installation most services are turned off. Enabling services is easy using check boxes. What services you will need depends on what you want to test or demo. Navigate toSystem/Servers. The next screen shows you the services we think make sense for a first test. You can always change the services configuration later.
Note: This guide describes the setup for a single server test system. You can later add additional hosts and automatically configure them using this admin UI. Distributed services and redundancy are configured automatically and all configuration is centralized for all services.
The 14.04 release allows for both the old and new User application to be used. Default is the old one and here is how to change that. Go to System/Admin Settings.
Access the User Application
You first have to create at least one new user. Then logout from the admin portal and log back in using this new user’s credentials.
There are different ways how users can be managed. Here we add some demo users manually. Click on the Users menu and select Users, then click on the Add New User hyperlink in the upper right corner of the table. Below is how it looks once the user data has been entered.
Extensions are offered automatically from an extension pool starting at extension 200. You can change this, but we go with it for now. The only information that is mandatory is a PIN for the user’s access to voicemail and a user password, but we highly recommend to at least enter a name.
Go ahead and add a couple of users to the system. Try fill-in more information, such as user profile information. There are a lot of additional service options. Browse the menu on the left and explore.
Note: the SIP password is auto-generated and only displayed if you click on Show Advanced Settings in the upper right corner. You need the SIP password for manually configured phones only.
Go to the User for whom you want to add a phone. From the User screen navigate toPhones using the left navigation.
If you configured sipXecs on an isolated subnet during installation, enabled the DHCP service, and enabled the Phone Auto-Provisioning service, then you are all set for auto-discovery of supported devices. Take a Polycom phone, reset its configuration if it is not new, and plug it into the network segment. It should automatically pick up a default configuration and come up with a provisional line configured and registered.
You can find all the auto-discovered devices in the table under Devices/Phones. These devices are able to make internal calls, but they are not yet assigned to a user. To assign a phone to a user go to Users/Phones and select an existing but unassigned phone.
Open the Add new phone drop-down dialog box and check whether the phone you would like to add (hard or soft) is on the list. If it is then sipXecs is able to provision your phone. Select it from the list and it get’s automatically assigned to the user. sipXecs now generates a configuration profile with default parameters that make sense for this particular user. Plug the phone into the network and restart it. Make sure the phone has the sipXecs server configured as its FTP server if DHCP does not provide it and make sure the FTP service is enabled. The phone will now load the configuration profile.
Note: sipXecs allows sophisticated configuration of all the parameters offered by supported devices. For a first test we suggest to go with default parameters.
Note: Make sure you press the SEND PROFILE button to actually generate the phone profile.
If your phone is not on the list then you have to manually configure it by going to the phone’s configuration manager. The necessary parameters typically are these. They can be obtained from the User configuration page.
Account Name A Friendly name for the account that only you see
User ID The user’s numeric extension
Domain SIP domain name or realm
Password SIP Password (not the PIN and not the User password.
Click on Show Advanced Settings to see the SIP password)
Display Name What others see as Caller ID when you call them
Auth Name The user’s numeric extension
The Counterpath X-Lite soft phone (free) is a good phone to try this with. If you cannot get it working with the above information you likely have some DNS issue. You can perform DNS tests going to System/DNS and then select Advisor.
Get some phones registered for the users you created. Once you have done that, attempt calling phone to phone. Depending on the phone model, the phone’s UIs displays registration status. You can also check registrations by going to the user’s configuration page and then selectRegistrations from the left menu. To see all phones go to Diagnostics/Registrations.
Internal extensions you can call:
Extension 100 Default auto-attendant
(make sure AA service is enabled)
Extension 101 Default voicemail extension
(make sure VM service is enabled)
sipXecs supports any codec supported by the participating end points. Default phone profiles are generated with a preference for high-definition audio. Experience the clarity and richness of sound of your new system.
sipXecs handles both voice and video dependent on the participating endpoint’s capabilities. Try it out! Media is always routed peer-to-peer over the most direct path as long as a routed network without NAT is used. This results in great voice and video quality.
There are two ways how you can connect to the PSTN: a) using an analog or T1/E1 gateway, or b) using a SIP trunk over IP.
If you have an analog or T1/E1 gateway available (the preferred brand is Audiocodes), you can configure it automatically or manually similar to how phones are configured. Since these gateways can be expensive and for the sake of this guide we focus on how to connect to a SIP trunking provider using voip.ms (http://voip.ms).
First you need to create an account with voip.ms. You have to have available a set of credentials (user name and password) and the provider’s hostname before you continue.
Go to the Gateways page under the Devices menu. Click on the Add new gateway… drop-down dialog box and select SIP trunk. On the page that appears (seen below), give the gateway a friendly name (such as ‘voipMS’, no spaces in names and only use letters and numbers), pick your provider from the User provider template drop-down dialog box and then enter the server address you like to use (voip.ms has presence in many cities like New York, Chicago, Atlanta, Dallas, etc.).
Click the Apply button when done and the left side menu will appear. Make sure the SIP Trunking Service (Role) is enabled under System/Servers/Telephony Services. Select ITSP Account from the left side menu to display the account information and fill-in Username and Password as received from voip.ms.
Once you have entered the information, click on Apply. To verify that your SIP Trunk is authenticating properly, click on the Diagnostics menu and select the SIP Trunk SBC Statisticsmenu item. This will display the following page:
If things are configured properly, under Registration Status, you should see Authenticated. If you see INIT, Authenticating, or Failed, you should re-check your ITSP account information. Make sure your firewall allows your server to connect out to the internet and make sure that your firewall has all SIP ‘helpers’ disabled.
If the ITSP account isn’t working properly, adding it to a dial plan still won’t make it work.
If your ITSP only sends inbound to an IP address outside your firewall, this is a more complex configuration and beyond the scope of this Easy Guide.
The next step we need to complete to enable outbound calling is to add the gateway to our dial plans. Click on the System menu and select the Dial Plans menu item. Click on the Long Distance dial plan entry to display the following page:
From the More actions… drop-down dialog box, select the ISTP gateway you created earlier, then check the Enabled box at the top of the page.
At this point, if your firewall cooperates and you are based in North America, you should be able to dial 91 followed by a 10-digit telephone number from a phone you have registered to the system. The prefix ‘9’ is optional. For outside of North America create a dial plan that fits your local numbering plan. It’s easy.
To configure inbound calls you have to make sure that an incoming call dialed to a certain DID number that the ITSP assigned to you gets routed to the correct internal extension. You can route incoming calls based on their DID to individual users, auto-attendants, conference bridges, and other service numbers.
To route an incoming call to the default auto-attendant, go to System/Dial Plans and selectAutoAttendant. Add the assigned DID number into the DID Number field in the middle of the page. Whether you need a ‘1’ prefix or not depends on your ITSP.
To route an incoming call to a specific user go to the user’s configuration page and enter the DID number into the Aliases field towards the bottom of the Identification page.
Go to Diagnostics/Call Detail Records to look at currently active or historic calls including failed calls.
The Voicemail service is enabled on the System/Servers/Telephony Services page. It is active for all users by default. To configure it go to the user’s configuration page under Unified Messaging.
You can enable a Personal Auto-Attendant on the user’s configuration screen under Personal Auto-Attendant. The user must record a prompt that explains the available options. This configuration can also be done by the user using the User Application.
The user manages voicemail using the User Application. Voicemail to email forwarding can be configured.
A FAX extension can be configured for the user. A FAX sent to this extension or DID will be received and forwarded as an email to the user’s email address.
sipXecs includes a fully featured Instant Messaging (IM) and Presence server based on the XMPP protocol. Enable IM and Presence as a service by going to System/Servers/Instant Messaging.
The IM / Presence feature is enabled for a user or a group of users by going to the user’s configuration page under Instant Messaging. The screen shot below shows Advanced Settings.
The default XMPP user name is the user’s extension. However, in many cases the user would like to use the email user name or other name instead. The IM password is the user’s password also used to login to the user application. For Phone Presence service to work the RLS service has to be enabled under System/Servers/Telephony Services.
Add users into groups using the Groups field on the user’s configuration page or go toUsers/User Groups. This will auto-populated the user’s IM roster with the contacts that share the same group.
MyBuddy is a nice chat bot application that you can enable under System/Servers/Instant Messaging/IMBot. It is configured on the user’s configuration page under MyBuddy. MyBuddy will show up automatically in the user’s roster.
Each user can be enabled with a personal conference room. Conferencing can be enabled for individual users or groups of users. Go to the user’s configuration page under Conferences.
Users can own several conference rooms. Each conference room is typically paired with a group chat room if IM is enabled.
Conference rooms have several configuration parameters. The admin can set default values and individual users can then manage their own conference and group chat rooms using the User Application.
The user’s group chat room can be found using an XMPP client and using the room discovery feature for group chat rooms.
Video conferencing is an experimental feature that can be enabled in the 14.04 release. Try it out!
A lot of other nice things have been left out from this guide, but we should have given you enough for you to now go an explore more.
sipXecs is based on a very innovative architecture. UCCS, Universal Cloud Communications Stack, is made for the cloud. It scales easily. It provides redundancy as needed. It is extremely resource efficient. It uses MongoDB as an open source distributed and partition tolerant database. It has configuration management built-in for extremely efficient and fully automated deployments, configuration, and updates. It runs virtual and can easily be packaged into containers.
We hope you enjoy sipXecs. We enjoyed building it and we are passionate about our work. Please contact us. We are anxious to hear from you.
sipXecs requires correct DNS settings to work. It can automatically configure its own DNS server or tell you what the settings need to be. To only test the admin UI, you don’t need DNS setup and can use the IP address, but it is still required to at least have the A record for the host set. Always start from the auto-generated DNS zone file as settings might have changed from release to release.
The following are the required records for a single server sipXecs system.
SRV records for cluster internal communication and fail-over:
Please follow the link below for much more detailed guidance:
http://wiki.sipfoundry.org/display/sipXecs/DNS+Concepts+for+sipXecs
To test DNS go to System/DNS/Advisor.
Example zone file generated by sipXecs for a single-server install when all services are enabled and for a server with hostname server in domain example.com (file located in /var/named ):
$TTL 1800
@ IN SOA ns1.example.com. root.example.com. (
65144324 ; serial #
1800 ; refresh, seconds
1800 ; retry, seconds
1800 ; expire, seconds
1800 ) ; minimum TTL, seconds
example.com. IN NS server
;; RECORDS: naptr
example.com. IN NAPTR 2 0 “s” “SIP+D2U” “” _sip._udp
example.com. IN NAPTR 2 0 “s” “SIP+D2T” “” _sip._tcp
;; RECORDS: srv
_sip._tcp IN SRV 30 10 5060 server
_sip._udp IN SRV 30 10 5060 server
_sips._tcp IN SRV 30 10 5061 server
_sip._tls IN SRV 30 10 5061 server
_sip._tcp.mwi IN SRV 30 10 5110 server
_sip._tcp.mwi.server IN SRV 10 10 5110 server
_sip._tcp.vm IN SRV 30 10 15060 server
_sip._tcp.vm.server IN SRV 10 10 15060 server
_sip._tcp.rr IN SRV 30 10 5070 server
_sip._tcp.rr.server IN SRV 10 10 5070 server
_xmpp-server._tcp IN SRV 30 10 5269 server
_xmpp-client._tcp IN SRV 30 10 5222 server
_xmpp-server._tcp.conference IN SRV 30 10 5269 server
_xmpp-client._tcp.conference IN SRV 30 10 5222 server
;; RECORDS: a
server IN A 198.2.99.157
If you let sipXecs manage DNS (default configuration after installation) it will auto-generate the zone file dynamically based on what services you have enabled. Make sure your clients (Web browser on your laptop and all phones and XMPP clients use this DNS server) or see these records when doing lookups.
The ISO image downloaded from SIPfoundry.org is most likely not the latest version. The ISO is rebuilt for every new major release, but for update releases of the stable version only RPM files are distributed. Therefore, after installation of the ISO image you should update your system to the most recent update release.
Here is how:
Login as root or sudo to root
Stop the sipXecs application
/sbin/service sipxecs stop
Run the update process
yum update
Restart the server
reboot
Hit by unexpected trouble? Keep in mind that 80% of all issues relate to DNS. Read our Wiki page on DNS configuration for your domain. Use the troubleshooting tools offered by sipXecs to diagnose DNS settings.
When it comes to voice or video quality issues, the culprit is most likely your network. If your Ethernet closet is a mess, has not been updated for a long time, or you have switches connected to switches we would look there first. As media does not go through the sipXecs server but is routed peer-to-peer, deploying a bigger machine will not help.
SIP trunking problems can be tricky as every provider is a little different. Your best bet is to invest in a professional SBC. It is well worth the investment.
The best way to get help is by using our Forum. You find it on the SIPfoundry Web site.
sipXecs supports full localization and multi-lingual deployments. Localization packs are available in RPM format from the SIPfoundry Download page. You can localize voice prompts, dial plans, and the entire admin and user Web UI.
Translations for the Web UI are community provided and often not quite up-to-date. RPM language pack files start with ‘sipxlang-xxx.noarch.rpm’ and there are 15 language packs available, including translations to Chinese, Japanese, French, Dutch, Italian, different flavors of Spanish, Brazilian, British English, Polish, and German. Make sure you install the necessary localization packs using the yum package manager before you start.
yum install sipxlang-xxx.noarch.rpm
Go to System/Localization to manage system localization.
Individual services can be localized too. For an example go to Features/Auto Attendants and select Operator. The Language drop-down should show all the languages installed.
If you’d like to help improve localization contact us using our Forum or send email to[email protected]. The full source code for all the language packs is available in our Github repository.
We call it the ‘god script’. You can find it in directory /usr/bin and you start it simply by typingsipxecs-setup as root.
It starts automatically after first login after a fresh install. It is reentrant so that you can use it again later to reset or reconfigure your system.
Type sipxecs-setup –help to see the list of options.
Want to know what it does? Run it with the –-verbose option. You can use this script to reset a system. It will force stop all processes and erase all data.
To build a cluster, the first server is installed as the master, and all subsequent hosts are first created in the sipXecs Admin UI. The new host is then started using the same image, and dedicated as a secondary host using this script. The master sipXecs host will take over from there and perform all necessary configuration to promote the new host into a specific role in the cluster.
sipXecs uses DNS SRV to provide automatic and instant fail-over and geo-redundancy. The sipXecs SIP Session Manager (proxy/registrar) is transaction state-full, but session stateless. This means that server failures have no impact on in-progress calls. If the server that initially setup a call fails, another server will take over if the user e.g. wants to transfer the call, put it on hold, or end it. This failover works globally and is completely transparent to the user. The sipXecs XMPP server is clustered for global scale using DNS SRV for fail-over. Media services scale horizontally.
The UCCS architecture is unique in that it allows full geo-redundant load sharing. You no longer have to build a cluster per region or continent with its own database and operations, but can create a fully globally distributed and load sharing single system, reducing the total number of required servers by up to 80% as compared to e.g. Cisco CM/HCS.
UCCS includes a distributed and partition tolerant database based on MongoDB. An instance of this database typically runs on each host or virtual instance, providing for local resiliency and fast transaction performance. Parts of the system can be separated off due to for example a network failure and continue to operate until rejoined.
Media streams do not traverse the sipXecs servers but are routed direct peer-to-peer. This provides for best possible audio / video quality and low latency. The sipXecs servers are not the bottleneck for scaling traffic. This also facilitates cloud deployments where servers reside in the cloud, but media stays on-premises.
For trunk redundancy gateways can be located anywhere with fail-over rules, allowing for the creation of resilient branch configurations. Gateways can be combined with SIP trunk connections over IP.
We get this question a lot. Both scaling UP and scaling DOWN is important.
sipXecs easily configures into a cluster with global redundancy. Instead of several independent clusters, one per continent or so, sipXecs allows you to build a truly geo-redundant system with global roaming and load sharing. The database used for transactions is distributed and partition tolerant, which makes it easy to create the resiliency needed by your application. Large production systems that we know exist in real companies scale to about 20,000 users per cluster. The actual system limit is not known, but believed to be quite a bit above that number. Voicemail scales horizontally, so do most other services. IM and presence (XMPP) was tested up to 100,000 registered clients, where we exhausted the capabilities of the test system. In such large scale deployments sipXecs has shown to be up to 10x cheaper to operate as compared to e.g. Cisco CM/HCS.
This is about reducing the total system resource footprint to a minimum achieving a cost point for cloud deployments required to target SMB customers. All of sipXecs, including all services, the management system and the database can reside on one single host or instance with very moderate specs (2 to 4 compute units, 4 GB of RAM, 10 to 16 GB of disk excluding voicemail storage). We believe this footprint can be further reduced packaging sipXecs into containers. See our architecture document for more info. We believe that this allows creating a hosted solution with more flexibility and more services for the customer at a cost point that is lower as compared to a Broadsoft multi-tenant solution. Contact us at [email protected] if you’d like to hear more about this.