Installing sipXecs
From InstallationWiki
| Official Page |
| Project Documentation |
| Download |
|
sipXecs can be installed by compiling for a specific Linux distribution, by RPM to an existing Linux installation or from a single CD ISO installer (an ISO is an image file of a CD that be used to burn a CD). This installation tutorial will focus only on the single CD ISO installer. Methods for installing from RPM or compiling sipXecs from source can be found in the sipXecs Wiki (linked at http://www.sipfoundry.org). This tutorial will cover:
- Completing the cabling requirements
- Completing the network infrastructure requirements
- Installing sipXecs
Contents |
[edit] Complete cabling requirements
Make sure that the network drops are available wherever phones are required. Review the notes collected for each user and phone to make sure that none are missed. By utilizing network drops for standard analog phones as well as IP phones, future cabling may not be required if an IP phone is desired at some point.
In most cases the demarc is in a location that is not particularly well suited for computer equipment. Extend the demarc where the gateways will be located. In the location of the gareway(s), the phone lines are broken out according to the type of connection required by the selected gateways. For example, most analog gateways require RJ-11 plugs, so have the phone lines broken out onto RJ-11 plugs so that typical phone patch cords can be used to connect to the gateway(s).
The following diagram illustrates how connection blocks are utilized along with a 25 pair feeder cable to extend the demarc to where the gateway equipment will be located.
Ensure that lightning protection is inserted on every phone line connecting to the system. Lightning protection can be located between the NID and the connection block, or just before the gateway.
Establish and test any new network connections between the network closets that will be required for any new network equipment.
[edit] Complete network requirements
Take care to verify that VLANs are configured properly and the QoS settings that will be required by the phones are set up according to the manufacturer's guidelines.
If virtual networks are being established, configure all trunking between switches. The PBX and gateways will not be able to tag their traffic for specific VLANs. Ensure that some ports are available that are natively configured (untagged) to exist in the phone VLAN. It is also a good idea to configure an extra port natively set in the phone VLAN for testing purposes.
If DHCP and DNS services are not going to be configured on the sipXecs server, it is important to have them configured and operational before installing sipXecs.
[edit] Installing sipXecs
Installation from the single CD installer is by far the easiest method. The single CD ISO can be obtained from the sipXecs Wiki. The easiest way to locate the Wiki is from the navigation bar at the SIPFoundry web site (http://www.sipfoundry.org). Download the latest stable release of the PBX ISO and burn it to a CD-ROM (http://sipxecs.sipfoundry.org/pub/sipXecs).
Insert the CD into the PBX computer and boot from it.
Press the Enter key and installation will begin.
Installation will begin and the preceding screen will be displayed with a progress bar indicating approximately how much of the installation is complete.
Once the initial part of the installation is complete, the server will reboot and the Linux login screen will appear.
As prompted, for the first time that you logon, enter root and press the Enter key and then enter the password as setup.
The first screen of the Setup Wizard will then appear, prompting you to press Spacebar or Enter to select Start.
The first piece of information entered is the password to be assigned to the system root user. The root user is the Linux system "superuser" account, which is used to administer the system. This account password should be reasonably complex and guarded. Enter the password twice and press the Tab key to select the OK button and press Enter.
The next screen will require some information from the Network planning section of Tutorial 2. These are important settings that are required to interoperate with existing network equipment, so revisit Tutorial 2 if there are any questions.
For the Hostname, enter the Fully Qualified Domain Name (FQDN) of the PBX. The FQDN is a concatenation of the hostname and the domain name. Enter the IP address of the PBX, the subnet mask, and the PBX's default gateway address. Tab to the OK button and press Enter.
If you fully understand how to configure DNS, you can elect to configure your own services. If you are unfamiliar with these services, sipXecs can configure and host them for you. If your system is on its own VLAN or operates isolated from an existing data network, it is suggested that you allow sipXecs to provide both DNS and DHCP services for the communications system network.
On the following screen, use the Tab key to select YES if you will use your own DNS server, or NO to have sipXecs as your DNS server (recommended). Use the Spacebar or Enter to make the selection.
The next screen (shown below) asks for DNS servers for forward lookup. OpenDNS.com's DNS servers were entered as an example.
Press the Tab key to select the OK button and press the Spacebar or Enter.
To get correct time, proper time zone settings are important for the PBX. Scheduled call forwarding, time stamps on messages, and other system services depend on accurate time.
For time purposes, select the continent on which the iPBX will be used.
Next, select a city in the same time zone as the sipXecs server and press Enter.
The screenshot shown below will allow you to utilize your own DHCP server or have sipXecs as the DHCP server for the network. Again, as with the DNS services, if your system is on its own VLAN or operates isolated from an existing data network, it is suggested that you allow sipXecs to provide both DNS and DHCP services for the communications system network.
Use the Tab key to select Yes or No, and to continue.
The next screen confirms that system-level settings are configured and we will now begin configuring service bootstrap parameters. Service bootstrap parameters are base settings for the sipXecs system.
Press the Enter key to continue.
The first configuration item identifies if it is the first sipXecs server or if we are adding another clustered system. Clustering allows many sipXecs servers to act as a single system for high availability and load balancing. See High availability installation later in this tutorial.
Press the Enter key to select the First Server option.
Next, enter the SIP Domain Name. The setup wizard will attempt to interpret this from the FQDN that was entered earlier.
Tab to the OK button and press Enter.
All services have now been configured. The services can be started or the system rebooted. A reboot is recommended.
Press the Tab to the Reboot button and press Enter.
Remove the installation CD and wait for the system to reboot to the login screen.
sipXecs is now installed and ready for configuration. To make sure that the sipXecs host system operates as efficiently as possible, a Linux GUI is not installed on the server. All of the administration for sipXecs is handled with a web GUI frontend called sipXconfig. Since there is no GUI on the server, (from another computer on the network) start a web browser and in the address bar enter the IP address or hostname of the sipXecs iPBX.
The administrator will be prompted to enter a new PIN (password) for the "superadmin" user when the sipXconfig is accessed for the first time.
Enter a secure alphanumeric PIN (twice) that cannot be easily guessed and click on the Apply button.
At this point, sipXconfig is ready for the administrator to begin configuring the system.
[edit] High availability installation
The installation wizard is able to install and configure a highly available system that consists of two physically separate servers. A High Availability (HA) system consists of a master server and a distributed server. Failover is taken care of by utilizing DNS SRV records that include information about master and distributed servers. The HA system allows redundancy of the call control system and load balancing of traffic. Media services such as voicemail, auto attendant, and other services such as ACD and sipXconfig are not redundant and will only run on one of the master server.
For a high availability installation, the master server must be installed and configured first. The installation procedure is similar to the steps taken in the previous section to install and configure a non-redundant system. Configuring the distributed servers of the cluster begins at the bootstrap portion of the setup. It is required that you run DNS and NTP services both on the master and distributed system unless you have a different setup that provides these services in a reliable way to both systems.
[edit] Install and configure the distributed server
The installation of the distributed server begins during the bootstrap portion of the installation. Configure the distributed server with a different IP address, enable DNS services, make sure that the DNS server used for forwarding DNS requests can resolve the name of the master server (use the master server IP if DNS is enabled on that server), and do not enable DHCP services if another server on the same network is handling DHCP requests.
Use the Tab key to move to the Adding A Server option and press Spacebar or Enter.
The following screenshot prompts the administrator to first add the new server on the master server (first server installed).
Before pressing any key on the distributed server that is being set up, open a web browser and log in as "superadmin" to the system administration for the master server. Click on the System menu and select the Servers menu item to display the following page:
Click on the Add Serve'r' hyperlink above the Status column.
The New Server page will then be displayed as seen in the following screenshot:
Enter the Hostname for the new server (this should be the fully qualified domain name). Next, enter the IP Address and a Description of the new server. A random password is generated and is displayed in the Password field. Write this password down as you will need it on the distributed server.
One or more roles can be enabled on each server. All roles can run on one single server or different roles can be distributed to several servers forming a cluster.
A high availability configuration can be configured by only enabling a redundant SIP router role. Roles can be moved to dedicated servers to improve performance.
Click on the OK button to add the new server.
The system administration session will return to the Servers page, shown next:
If prompted at the top of the screen, click on the here hyperlink to restart the services that need to be restarted.
The First Distributed Server will appear in the list of servers and have a status of Uninitialized.
Return to the distributed server's console setup routine and press Enter.
The setup will then display the following screen requesting information about the master server:
For the Master Hostname, enter the FQDN of the master server and then enter the server setup password that was noted when the server was added on the master system. Press Tab to move to OK. Press Space or Enter to select the option.
The installation wizard will now complete the setup and pull required information from the master server.
Press Tab to move to the R'eboot' option and press Enter to reboot the completed system.
[edit] Verify DNS and DHCP operation
Before continuing with the installation process, it is important that DNS and DHCP are both operating properly. sipXecs relies heavily on DNS, especially for HA installation, to function properly.
[edit] Single PBX testing
Log in to the PBX as the 'root' user. Verify that all of the following commands return the expected results:
ping sipx ping sipx.your.domain dig -t A sipx.your.domain dig -t SRV _sip._tcp.your.domain dig -t SRV _sip._udp.your.domain
The following are the expected results for each of the above PING tests (expect different IP addresses and domain names; press Ctrl+C to break continuous PING):
[root@sipx ~]# ping sipx PING sipx.xyzcompany.com (172.16.1.2) 56(84) bytes of data. 64 bytes from sipx.xyzcompany.com (172.16.1.2): icmp_seq=1 ttl=64 time=0.043 ms 64 bytes from sipx.xyzcompany.com (172.16.1.2): icmp_seq=2 ttl=64 time=0.031 ms 64 bytes from sipx.xyzcompany.com (172.16.1.2): icmp_seq=3 ttl=64 time=0.029 ms 64 bytes from sipx.xyzcompany.com (172.16.1.2): icmp_seq=4 ttl=64 time=0.033 ms --- sipx.xyzcompany.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.029/0.034/0.043/0.005 ms
Note that the first line returned should return the FQDN of the PBX and not just the host name.
[root@sipx ~]# ping sipx.xyzcompany.com PING sipx.xyzcompany.com (172.16.1.2) 56(84) bytes of data. 64 bytes from sipx.xyzcompany.com (172.16.1.2): icmp_seq=1 ttl=64 time=0.043 ms 64 bytes from sipx.xyzcompany.com (172.16.1.2): icmp_seq=2 ttl=64 time=0.031 ms 64 bytes from sipx.xyzcompany.com (172.16.1.2): icmp_seq=3 ttl=64 time=0.029 ms 64 bytes from sipx.xyzcompany.com (172.16.1.2): icmp_seq=4 ttl=64 time=0.033 ms --- sipx.xyzcompany.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.029/0.034/0.043/0.005 ms
The first DIG test checks that the FQDN is working properly. The test should return results similar to the following:
[root@sipx ~]# dig -t A sipx.xyzcompany.com ; <<>> DiG 9.3.4-P1 <<>> -t A sipx.xyzcompany.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22369 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;sipx.xyzcompany.com. IN A ;; ANSWER SECTION: sipx.xyzcompany.com. 86400 IN A 172.16.1.2 ;; AUTHORITY SECTION: xyzcompany.com. 86400 IN NS ns1.xyzcompany.com. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Nov 27 06:46:23 2008 ;; MSG SIZE rcvd: 65
The next DIG test checks the operation of the SIP TCP service record for the SIP domain.
[root@sipx ~]# dig -t SRV _sip._tcp.xyzcompany.com ; <<>> DiG 9.3.4-P1 <<>> -t SRV _sip._tcp.xyzcompany.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12430 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;_sip._tcp.xyzcompany.com. IN SRV ;; ANSWER SECTION: _sip._tcp.xyzcompany.com. 86400 IN SRV 1 0 5060 sipx.xyzcompany.com. ;; AUTHORITY SECTION: xyzcompany.com. 86400 IN NS ns1.xyzcompany.com. ;; ADDITIONAL SECTION: sipx.xyzcompany.com. 86400 IN A 172.16.1.2 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Nov 27 06:56:17 2008 ;; MSG SIZE rcvd: 103
The last DIG test checks the operation of the SIP UDP service record for the SIP domain.
[root@sipx ~]# dig -t SRV _sip._udp.xyzcompany.com ; <<>> DiG 9.3.4-P1 <<>> -t SRV _sip._udp.xyzcompany.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33618 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;_sip._udp.xyzcompany.com. IN SRV ;; ANSWER SECTION: _sip._udp.xyzcompany.com. 86400 IN SRV 1 0 5060 sipx.xyzcompany.com. ;; AUTHORITY SECTION: xyzcompany.com. 86400 IN NS ns1.xyzcompany.com. ;; ADDITIONAL SECTION: sipx.xyzcompany.com. 86400 IN A 172.16.1.2 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Nov 27 07:00:37 2008 ;; MSG SIZE rcvd: 103
To test DHCP functionality, connect a computer to the same network as the PBX (that is, if the PBX is in a phone VLAN, connect the computer to that VLAN). Verify that the computer gets an appropriate IP address from the DHCP service on the PBX and that the DNS domain name of the computer is the same as the SIP domain name.
If testing from a Linux or Mac-based system, utilize the same commands as just described to test DNS functionality. The same results are expected.
If testing from a Windows based system, use the following command to test DNS functionality from a DOS command line:
ping sipx ping sipx.your.domain nslookup >set q=srv _sip._tcp.your.domain _sip._udp.your.domain quit
Following are the expected results for each of the above DOS command-line PING tests (expect different IP addresses and domain names):
F:\>ping sipx Pinging sipx.xyzcompany.com [172.16.1.2] with 32 bytes of data: Reply from 172.16.1.2: bytes=32 time=181ms TTL=62 Reply from 172.16.1.2: bytes=32 time=101ms TTL=62 Reply from 172.16.1.2: bytes=32 time=124ms TTL=62 Reply from 172.16.1.2: bytes=32 time=147ms TTL=62 Ping statistics for 172.16.1.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 101ms, Maximum = 181ms, Average = 138ms
Note that the first line returned should return the FQDN of the PBX and not just the host name.
F:\>ping sipx.xyzcompany.com Pinging sipx.xyzcompany.com [172.16.1.2] with 32 bytes of data: Reply from 172.16.1.2: bytes=32 time=181ms TTL=62 Reply from 172.16.1.2: bytes=32 time=101ms TTL=62 Reply from 172.16.1.2: bytes=32 time=124ms TTL=62 Reply from 172.16.1.2: bytes=32 time=147ms TTL=62 Ping statistics for 172.16.1.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 101ms, Maximum = 181ms, Average = 138ms
The nslookup tests are combined as follows:
F:\>nslookup Default Server: sipx.xyzcompany.com Address: 192.168.100.10 > set q=srv > _sip._tcp.xyzcompany.com Server: sipx.xyzcompany.com Address: 172.16.1.2 _sip._tcp.xyzcompany.com SRV service location: priority = 0 weight = 0 port = 5060 svr hostname = sipx.xyzcompany.com sipx.xyzcompany.com internet address = 172.16.1.2 > _sip._udp.xyzcompany.com Server: sipx.xyzcompany.com Address: 172.16.1.2 _sip._udp.xyzcompany.com SRV service location: priority = 0 weight = 0 port = 5060 svr hostname = sipx.xyzcompany.com sipx.xyzcompany.com internet address = 172.16.1.2 > quit
The expected results are very similar to the results obtained earlier from the Linux DNS tests.
[edit] High availability PBX testing
Testing DNS functionality for an HA installation is similar to the testing for a single PBX. The results for the SRV record tests, however, should return a series of records with their priority and weight with the master server being preferred over the distributed server. Log in to each of the PBXs as the 'root' user. Verify that all of the following commands return results similar to those in the Single PBX testing section covered earlier:
ping sipx1 ping sipx2 ping sipx1.your.domain ping sipx2.your.domain dig -t A sipx1.your.domain dig -t A sipx2.your.domain dig -t SRV _sip._tcp.your.domain dig -t SRV _sip._udp.your.domain
The DIG service record tests (those beginning with dig -t SRV) should again return information similar to the DIG tests in the Single PBX testing section except that two servers with different IP addresses and priorities will be in the DIG answer.
To test DHCP functionality, connect a computer to the same network as the PBX (that is, if the PBX is in a phone VLAN, connect the computer to that VLAN). Verify that the computer gets an appropriate IP address from the DHCP service on the PBX and that the DNS domain name of the computer is the same as the SIP domain name.
If testing from a Linux or Mac-based system, utilize the same commands as above to test DNS functionality. The same results are expected.
If testing from a Windows-based system, use the following command to test DNS functionality from a DOS command line:
ping sipx1 ping sipx2 ping sipx1.your.domain ping sipx2.your.domain nslookup >set q=srv _sip._tcp.your.domain _sip._udp.your.domain
The nslookup tests, like the DIG tests, should return information similar to the nslookup tests above in the Single PBX testing section except that two servers with different IP addresses and priorities will be in the results.
[edit] Source
The source of this content is Chapter 3: Installing sipXecs of Building Enterprise Ready Telephony Systems with sipXecs 4.0 by Michael W. Picher (Packt Publishing,2009).
