Case Study: Resort Hotel & Cabins Company Hybrid VoIP / Traditional Telephony Upgrade & Expansion
Introduction
A French Mediterranean beach resort hotel and cabins company1 (hereafter, “The Customer”) was expanding and modernizing their total unit and existing units at their location over the Winter of 2007. A shift in their clientele showed increased business-related traffic, such as retreats, weekend meetings and tiger-team think-tank sessions. As a result, they were planning on a significant Internet connection to support these customers, as well as an expansion of phone system services. They concluded that Voice Over Internet Protocol (VOIP) technology was a logical possibility to reduce cable-plant management issues as well as long-term total cost of ownership (TOC).
Background |
The original configuration and buildings were:
- Two primary buildings of 40 and 30 units respectively. These were already wired for analog telephone service, which the customer did not wish to “rip and replace”.
- Eleven cabin-styled buildings of three units each. The cabins were also wired for analog, however, environment issues were forcing a complete rebuild of the units.
The planned additions as part of the project were:
- Nine more cabin-style buildings
- A third primary building of 30 units
- Approximately 16 more administration phones scattered across the facilities.
- Replace the trio of aging FAX machines with a less paper-intensive service.
The new construction would be wired with CAT6 cable to support future gigabit application. The total unit count would then be 160 units, with one phone per unit.
Customer requirements for the PBX and services included:
- 100% control of the system needed to be from the front desk as well as the duty manager’s office.
- Due to its geographic location, there needed to be as much remote service capability as possible to avoid customer problems associated with non-functional phones.
This was presented to the team as a “Request For Proposal” from the client, who was not fully certain this list of needs was achievable without an unjustifiably large capital expenditure. We proceeded to assess the technologies available and provide the customer with a full proposal and costing. We were selected from a group of three final contenders to deliver the solution.
The PBX |
The old, un-scaleable existing PBX was removed and sold to a technology refurbisher. It was replaced with a trio of Intel-based PC servers running 2 Xeon 1Ghz processors each, with 4Gb of RAM and RAID mirrored 80Gb SAS disks, and three network cards per system. A 5KVa “smart” UPS was installed to protect the PBX systems and related gear.
Each server was installed with Linux CentOSi and a current version of Digium’s Asterisk Free Open Source Software (FOSS) PBXii. The first two servers were configured with Linux high-availability “heartbeat” servicesiii to allow sub-six-second fail-over times. One machine was the “live” PBX, and the other was the “hot standby”. The third machine was loaded with a FOSS virtual FAX modem stack called IAXModemiv and a FOSS FAX server software package called HylaFAXv.
The Customer converted all incoming copper pairs from France Telecom to a pair of 32-channel voice E1s from Orange Business Systemsvi. A third data-only E1 was also brought in and terminated on a fourth server identical to the PBXs, only sporting four network cards and running a Linux IPTablesvii firewall.
The voice E1s were terminated on a Redfoneviii foneBRIDGE ™ Time Division Multiplexing Over Ethernet (TDMoE) device. This device was dynamically reprogrammed to direct the TDMoE stream to which every PBX was the “Live”. Since it is a solid-state unit with no moving parts and its software load is externally managed by the “Live” PBX, it is extraordinarily reliable.
The Customer sourced an Internet Telephony Service Provider (ITSP) with pan-European termination and origination, called WideVOIPix. This allowed them to add new phone numbers in four other countries as part of the project without substantial cost. These numbers terminated directly via SIP VoIP onto the Asterisk PBX stack. In addition, any long distance calls placed were sent via this connection whenever possible to avoid international long-distance calling charges.
One network interface card (NIC) was on the data LAN, the second was on the VoIP LAN, and the third was on the TDMoE LAN. This ensured the best possible bandwidth and NIC processor availability for the VoIP environment.
This “Hybrid” configuration of digital E1 and VOIP allowed the greatest flexibility, cost control and reliability.
Avoiding Rip And ReplaceThe existing analog phones were either replaced or refurbished as part of the plan. The phones were plugged into a stack of AudioCodesx Analog-to-SIP gateway devices. These devices were connected to the Asterisk PBX stack, allowing the existing analog phones to work with the VoIP-based PBX. It also allowed the modem systems for the fire-alarm, security alarm and elevator maintenance controllers to place calls as per normal. |
Phones for New Customer UnitsThe phones for the new customer units were Thomson ST2030s, which are sleek, euro-styled business-grade SIP VoIP phones. The phones were at a reasonable price to quality point and ultimately, The Customer just preferred how they looked and sounded against competitor devices. Each room was wired with two RJ45 100Mb Ethernet jacks, which were cabled via CAT6 back to managed 3Comxi switches. Data was segregated to one physical LAN, while VoIP was kept on another, as noted above. |
FAX Server with FAX to EmailThe FAX numbers were mapped to the digital E1 lines and directed internally via IAX2 trunk from the “live” PBX taking the calls to the HylaFAX server. It was decided to allow up to a maximum of five lines on the digital E1s to be in use for facsimile transmission and receipt. Since the “virtual FAX modems” were essentially free, the limitation was entirely based upon The Customer’s comfort level with the possibility of busy signals on incoming calls during peak periods. Hotel clients could provide the Front Desk with an email address during sign-in, and have FAXes sent to the Hotel to their attention forwarded to their email as PDF as a complimentary service. Incoming FAXes were routed based on a set of rules provided to us by The Customer, with information such as the Caller ID, destination number or time of day; FAXes were immediately delivered as PDF via email to the intended recipient. FAXes which “fell through” the rules-set were delivered as emailed PDF to the “FAX Master” account, who was a full time secretary. |
Administration Phones, Including DECT and WiFiThe Customer was sufficiently pleased with the ST2030 phones that they deployed them as their office and administration phones as well. The only notable exceptions were the Front Desk “Operator” phone which was an expanded ST2030 with four multi-line-button side-cars added, a trio of Thomson DECT cordless SIP phones, and a pair of Linksysxii WIP300 WiFi phones used by grounds staff. Several 3Com WiFi POPs had been placed around the resort, and these units allowed “find-me/ follow-me” call routing for staff who had to be out-and-about. |
Front Desk Operations, FeaturesThe Front Desk work-flow was the most demanding part of the project. The company designed and developed a custom web-based UI that allowed a desk clerk to manage the shift-to-shift behavior of the PBX system. A Client checking in would have the phone in their room enabled for outside calling by the Clerk. By default, the phones could only call other room and office phones, or public emergency services. Enabling or restricting a phone was done by a tap of a finger on a touch-screen. The system noted the customer’s name, last four digits of their credit card and their room number then issued a 4-digit PIN code for voicemail. This was printed out as part of the “Welcome and Check in” brochure they were given. Any time a customer placed a call, the Call Data Record (CDR) was recorded to a MySQLxiii database running and replicated across all three PBX servers. A near-real-time display showed every extension currently in the system, its status (enabled was green, restricted was yellow, off the wire was red), an icon indicating on hook or off hook, the Client name and number of voice mails waiting for them. A further indicator showed if a wake-up call was keyed into the system. Clients could request a wake-up call by calling the front desk. The Clerk would tap their extension on the touch-screen and be presented with a screen to either check the client out or set up a wake up call. The system handled wake-up calls automatically by calling the room, playing the time, the local weather report and accepting a “snooze” request by the person answering the phone. Wake-up statuses could be viewed by the Front Desk or Management staff. When the Client checked out, the system ran a billing report against the MySQL CDRs and then against a Management-configured rate-card. This bill was then added to their room bill. The phone status was then automatically toggled to “Restricted”, the voice mails in the system removed and pending wake-up calls wiped; all at the touch of a finger. Business-class customers could also use their phones for call-conferences and even request calls to be recorded. These were both cost-add features and had to be requested from the Front Desk. Features such as music on hold, call transfers and other important niceties were all part of the system. |
Management Operations, FeaturesManagement could naturally access the same UI as the Front Desk staff, using a mouse instead of a touch-screen. In addition, they could call up prior billing items for a given room or a given client/ credit-card pair. They also had access to a system “health check” screen that showed the status of every piece of the system in a “traffic light” status format. Which PBX was “Live”, the condition of the FAX server, the load on the VoIP and digital E1 trunks, memory, CPU and disk usage on all three PBX servers, even the status of the UPS system was visible. Call recordings of all office and “restricted” status phones were also available for review as MP3 downloads. Long-distance rate-card management could also be handled from here. |
Remote Service & Support CapabilityThe firewall server was running the FOSS version of OpenVPNxiv. This held a “tunnel” open to our office monitoring servers which were running Nagiosxv , a FOSS monitoring solution comparable to HP-OpenView or others. This allowed us to have an at-a-glance overview of the system in France, from Montreal, Canada. In addition, we could remotely log into the system to configure phones, update software, and even power-cycle machines off and on. |
Each screen had a “call for help” link which triggered an alarm on our system. We could then either call, instant message (IM) or email to contact the user who triggered the alarm, depending on their indicated urgency of issue.
Costing, Today’s EquivalentsAs a result of changing markets (Thomson, for example, no longer exists), emerging technologies (HD Sound, 802.11g WiFi), an updated design/ cost chart is most relevant: |
Conclusion |
The project, as delivered in 2007, was valued at roughly $100,000 CAD. At the time, The Customer indicated to us this was ½ the next highest quote and neither other competitor could deliver the feature-set we were promising. They realized a Return on Investment (ROI) of 49 months, simply by the dramatic reduction in long-distance fees they were paying to France Telecom; their bill was nearly cut in half. In addition, as noted above in “3.” on page 2, they were able to substantially increase their marketing reach by offering local contact numbers in four other countries with no increase in cost. This would have been unthinkable with a traditional solution.
By using VoIP to TDM converters in the project, The Customer was able to retain all the benefits of both types of telephony. This “Hybrid” system gave all the robustness and call quality normally associated with local TDM calling, but allowed the creation of a custom application for managing the Front Desk work-flow that integrated the telephony management and billing into the process with ease. In addition, more services and features were added, increasing the over-all business value of the phone system, yet keeping capital expenditures well within budget.
The project was considered a substantial success by The Customer. They stated repeatedly that they were both pleased and excited by both the achievement of the desired results, as well as the possibility for future features and services to their clients.
1Name cannot be revealed due to NDA obligations.
iLinux CentOS – http://www.centos.org/
iiDigium’s Asterisk – http://www.asterisk.org/
iiiHigh-availability Linux – http://www.linux-ha.org/
ivIAXModem Virtual FAX Modem – http://iaxmodem.sourceforge.net/
vHylaFAX FAX Server – http://hylafax.sourceforge.net/
viOrange Business Systems – http://www.orange.com/
viiIPTables Firewall – http://www.netfilter.org/
viiiRedfone foneBRIDGE T1/E1 TDMoE devices – http://www.red-fone.com/
ixWideVoIP ITSP – http://www.widevoip.com/
xAudioCodes Analog-to-SIP gateways – http://www.audiocodes.com/
xi3Com Routers & Switches – http://3com.com/
xiiLinkSys WiFi SIP phones, now a Cisco Company – http://www.linksysbycisco.com/
xiiiMySQL “The world’s most popular open source database” – http://mysql.com/
xivOpenVPN “SSL VPN solution” – http://openvpn.net/index.php/open-source.html
xvNagios Network Monitoring – http://www.nagios.org/
About the author and project: This project was done as part of Michel’s tenure at a previous employer. Michel now owns and operates his own VoIP Integration & Solutions Company, JKL-5 Groupe.
Michel R. Vaillancourt at JKL5Group
Asterisk Systems Rocketeer & CEO
+1.514-907-9429 (w)
+1.514-512-1677 (m)
+1-416-479-0632 (o)
20 Hillcrest Ave
Suite 1
Lachine QC H8R 1J1
Canada
No comments:
Post a Comment