34,79 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Open source telephony systems are making big waves in the communications industry. Moving your organization from a lab environment to production system can seem like a daunting and inherently risky proposition. Building Enterprise Ready Telephony Systems with sipXecs delivers proven techniques for deploying reliable and robust communications systems.
Building Enterprise Ready Telephony Systems with sipXecs provides a guiding hand in planning, building and migrating a corporate communications system to the open source sipXecs SIP PBX platform. Following this step-by-step guide makes normally complex tasks, such as migrating your existing communication system to VOIP and deploying phones, easy. Imagine how good you'll feel when you have a complete, enterprise ready telephony system at work in your business.
Planning a communications system for any size of network can seem an overwhelmingly complicated task. Deploying a robust and reliable communications system may seem even harder. This book will start by helping you understand the nuts and bolts of a Voice over IP Telephony system. The base knowledge gained is then built upon with system design and product selection. Soon you will be able to implement, utilize and maintain a communications system with sipXecs. Many screen-shots and diagrams help to illustrate and make simple what can otherwise be a complex undertaking. It's easy to build an enterprise ready telephony system when you follow this helpful, straightforward guide.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 319
Veröffentlichungsjahr: 2009
Ähnliche
Table of Contents
Building Enterprise-Ready Telephony Systems with sipXecs 4.0
Michael W. Picher
Building Enterprise-Ready Telephony Systems with sipXecs 4.0
Copyright © 2009 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: June 2009
Production Reference: 1170709
Published by Packt Publishing Ltd. 32 Lincoln Road Olton Birmingham, B27 6PA, UK.
ISBN 978-1-847196-80-4
www.packtpub.com
Cover Image by Parag Kadam (<[email protected]>)
Credits
Author
Michael W. Picher
Reviewer
Anthony Graziano
Scott Lawrence
Acquisition Editor
Sarah Cullington
Development Editor
Dilip Venkatesh
Technical Editor
Aditi Srivastava
Indexer
Hemangini Bari
Editorial Team Leader
Abhijeet Deobhakta
Project Team Leader
Priya Mukherji
Project Coordinator
Lata Basantani
Zainab Bagasrawala
Proofreader
Chris Smith
Production Coordinator
Dolly Dasilva
Cover Work
Dolly Dasilva
About the Author
Michael W. Picher is an industry veteran with over 20 years of experience in Information Technology consulting. Michael brings a network engineer's perspective to the Telephony business. After receiving a Bachelor of Science degree in Computer Engineering from the University of Maine, Michael worked hard to build up a computer manufacturing business, which he left in the mid-90s. Following the manufacturing endeavor, Michael worked with two close friends to build what became one of Maine's largest home-grown technology consulting and software development firms. After successfully selling the consulting business to a large out-of-state firm, Michael turned his attention to the growing IP Telephony space. Michael has helped successfully deploy some of the region's largest IP-based communications systems and the infrastructure required to support those systems.
Away from technology, Michael enjoys life with his wife Debra and son Matthew on their large, wild blueberry farm in rural Maine. Snowmobiling and hunting are the family choices for fun, and Michael is also a longtime Autocross fanatic with multiple class wins in his beloved Mini Cooper S.
I'd like to thank my wife Debra for her support while writing this book, my son Matthew for bringing joy to our lives, and my parents who have always been there to keep me pointed in the right direction. I'd also like to thank Tony Graziano and Scott Lawrence, for their contributions and technical review, and the sipXecs development team and community without whom we wouldn't have this wonderful product. A thank you is also due to the team at Packt Publishing for keeping things moving forward and helping to create an excellent final product.
About the Reviewer
Anthony Graziano has spent the last 25 years working in Information Technology and telecommunications. Recruited by a national carrier from his position at a multistate financial services firm concentrating on IBM mainframes and communications, he worked as a data specialist for one of the largest US facilities-based carriers. After deciding to focus on microcomputing technology, he worked for a Virginia-based consulting and services firm, which he helped to grow before it was purchased by a national firm.
Today he operates a CLEC in Virginia (Cavalier Broadband) with a dedicated focus on data services. His growing consulting practice, myITdepartment, helps commercial clients to identify emerging technologies such as VoIP and SaaS, so they can more easily adapt to changing business trends.
He lives in Charlottesville, Virginia, with his wife Lisa and their three daughters. He enjoys saltwater fishing, especially on the Northern Neck of the Cheaspeake Bay, with friends and family as often as he can.
Preface
Open source telephony systems are making big waves in the communications industry. Moving your organization from a lab environment to production system can seem like a daunting and inherently risky proposition. Building Enterprise Ready Telephony Systems with sipXecs delivers proven techniques for deploying reliable and robust communications systems.
Building Enterprise Ready Telephony Systems with sipXecs provides a guiding hand in planning, building, and migrating a corporate communications system to the open source sipXecs SIP PBX platform. Following this step-by-step guide makes normally complex tasks, such as migrating your existing communication system to VoIP and deploying phones, easy. Imagine how good you'll feel when you have a complete, enterprise-ready telephony system at work in your business.
Planning a communications system for any size of network can seem an overwhelmingly complicated task. Deploying a robust and reliable communications system may seem even harder. This book will start by helping you understand the nuts and bolts of a Voice over IP Telephony system. The base knowledge gained is then built upon with system design and product selection. Soon you will be able to implement, utilize, and maintain a communication system with sipXecs. Many screenshots and diagrams help to illustrate and make simple what can otherwise be a complex undertaking. It's easy to build an enterprise-ready telephony system when you follow this helpful, straightforward guide.
What this book covers
Chapter 1 introduces some important telephony concepts to establish some necessary background information and an overview of sipX Enterprise Communications Server (sipXecs), its features, and its functionality.
Chapter 2 covers data collection about the existing systems, equipment selection, and the planning for phone system programming.
Chapter 3 covers steps involved in completing the cabling requirements, network infrastructure requirements, and installing sipXecs. In this chapter we learn to install the base PBX operating system and software. We also learn some important testing steps for verifying DNS and DHCP functionalities.
Chapter 4 covers creating and managing user accounts, managing the extension pool, utilizing user groups, and importing users. We also explore how to use phantom users for voicemail-only mailboxes and for some advanced call routing needs.
Chapter 5 covers the typical day-to-day functions that a communications systems manager needs to perform. The reader gets a good basic knowledge of adding users and phones to the system in this chapter.
Chapter 6 covers adding managed and unmanaged gateways, setting up the Session Border Controller, and working with Dial Plans.
Chapter 7 covers the configuration of sipXces server features. sipXecs has several server-side features that provide additional functionality. These functionalities are not otherwise available in the phones themselves. Many of the basic features will be covered in this chapter while some of the more advanced features will be described in Chapter 9.
Chapter 8 covers all of the information needed as an administrator to help the users acclimatize to their new communications system.
Chapter 9 explores the built-in conference services provided by sipXecs and then explores some more advanced sipXecs call routing features. It also covers some call routing tricks that will find use with the sipXecs installation.
Chapter 10 covers the configuration of ACD services. It also covers how to enable and monitor their operation.
Chapter 11 explores various system maintenance tasks and steps that can be taken to keep the phone system secure.
A glossary is also included at the end of the book. This appendix includes all the important words and terms used throughout the book.
What you need for this book
sipXecs can be installed from a single CD installer. The recommended system should have the following components:
Who this book is for
This book is written for network engineers who have been asked to deploy and maintain communications systems for their organizations.
Conventions
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text are shown as follows: "The nslookup tests are combined."
A block of code is set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "Under Quick Links on the right side of the page is an Add Line hyperlink."
Note
Warnings or important notes appear in a box like this.
Note
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an email to <[email protected]>, and mention the book title via the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book on it, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration, and help us to improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the let us know link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata added to any list of existing errata. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or web site name immediately so that we can pursue a remedy.
Please contact us at <[email protected]>with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at <[email protected]>if you are having a problem with any aspect of the book, and we will do our best to address it.
Chapter 1. Introduction to Telephony Concepts and sipXecs
In this chapter we'll introduce some important telephony concepts to establish some necessary background information. Then we'll move on to an overview of sipX Enterprise Communications Server (sipXecs), its features, and its functionality.
Traditional phone system concepts
There are two types of traditional phone systems, PBXs and Key Systems. A Private Branch Exchange (PBX) is typically found in larger organizations. Key telephone systems that allow users to directly select outside lines via keys on the handsets were designed with smaller organizations in mind. Both types of systems typically consist of interfaces to a telecommunications provider, interfaces to telephone handsets, a voicemail system for auto attendant and leaving messages, and call-routing logic.
The traditional PBX is usually thought of as being housed in a cabinet with various interfaces and logic boards inserted as cards into a backplane across which all of the cards can communicate. These backplanes are vendor specific, so you are typically locked in to purchase all cards and phones from a single vendor. Additionally, many first-generation IP-based phone systems may also be thought of as traditional systems. These early IP systems use proprietary signaling over IP or protocols that have fallen out of favor (MGCP/H.323).
The PBX communicates with the outside world from the interface to a telecommunications provider. In a traditional PBX, this interface is typically some sort of analog circuit (loop-start or ground-start) or digital circuit (E1/T1, ISDN, or Primary Rate Interface [ PRI]).
The telephone set interface is how the PBX connects with the various user devices that it is in direct control of. This is traditionally an analog interface to a limited-feature phone (like a typical home telephone) or a digital interface to a more feature-rich phone.
Voicemail systems in the traditional PBX are designed to handle recording and playback of messages to users of the system, notifying the users they have messages via a Message Waiting Indicator ( MWI), and also automated attendant duties. The automated attendant's function is to answer inbound phone calls, play a message, and wait for a caller to enter an option or extension.
The call-routing logic in a phone system determines where calls route to, based on a number that was dialed (be that an extension on the system or an external phone number). Other factors may also come in to play with call routing such as permissions, time of day, what line a call came from, and so on.
Telecommunications provider interface
The interface to a traditional telecommunications provider (a phone company) can take different forms depending on how your calls are being delivered. If your calls are being delivered by a traditional provider over E1, T1, PRI, BRI, or analog line, this interface device is a hardware-based gateway.
E1s, T1s, and PRIs are all digital circuits that can carry multiple conversations. E1 is a physical layer protocol, much like Ethernet, that defines a 2Mbps pipe. This pipe can be used for data—split into 32 64Kbps communications channels—or a mixture. If the pipe is used for communications channels, 30 of the channels can carry telephone conversations and the remaining 2 carry signaling and timing information.
A T1 is similar to an E1, and it is common in North America. T1s are 1.544Mbps pipes that can carry 24 telephone channels. There are no signaling channels on a T1. Also, like an E1, T1s can be channelized and utilized to deliver voice and data.
E1 and T1 circuits have some problems associated with them. They are limited in what information they can carry and the circuits are relatively slow to set up. ISDN signaling is a more modern protocol that was designed to overcome these problems. On E1s, EuroISDN signaling is standard. On T1s, different providers utilize different standards. NI1, NI2, DMS100, and DMS250 are all examples of ISDN signaling protocols, each delivering different levels of functionality.
A PRI (Primary Rate ISDN) is an E1 or T1 with ISDN signaling running on top of it. ISDN signaling provides reliable call setup and tear-down detection, as well as detailed information about each call. In the UK, a PRI is also referred to as ISDN30. Voice channels on a PRI are referred to as B channels and the signaling channels are referred to as D channels. On an E1, a PRI will provide 30 B channels of voice and utilize one of the signaling channels as the D channel. Since T1s have no signaling channels, a PRI on a T1 will utilize one of the channels as a D channel and have 23 B channels for voice.
As a cheaper alternative to PRI,BRI (Basic Rate ISDN) may be offered in some areas. A BRI has 2 64Kbps B channels and a single 16Kbps D channel for signaling. In the UK, a BRI may also be called ISDN2e.
Analog lines from local telephone companies come in a couple of different flavors, both delivered over a pair of copper wires. They will be referred to as Ground Start Trunks (GST) or loop start circuits. Ground start circuits provide disconnect notification by actually grounding the circuit (when a caller hangs up the phone), which is also called answer and disconnect supervision. Loop start analog circuits are the more typical home and key system phone lines. Loop start lines use either a polarity reversal (called battery reversal), or removal of the line voltage (battery drop) for answer and disconnect supervision.
Telephones on a traditional phone system
Telephone sets on a traditional phone system will interface to the system by using one of the one of three methods: analog, digital, or via IP.
Analog phones are usually the same sort of phones you might find in a residence. They can provide signaling to the PBX for special functionality by flashing the hook switch and utilizing different DTMF codes. Dial Tone Multi Frequency is the sounds you hear when you push the dial pad buttons of a phone. Analog phones need to be manually configured as there is no means for passing codes down to phones and programming any special keys that may be on the phones.
Digital phone sets provide higher functionality and programmability for phone systems. They are proprietary to each vendor and type of phone system. Digital sets can be programmed centrally. They provide excellent call quality and usually have many buttons that can be programmed to provide different functionality to the user. The majority of phones shipped with phone systems were digital until 2005/2006 when IP phone sets surpassed them in total numbers shipped.
Many traditional phone systems vendors have seen the advantages of an IP-based system and have adapted their phone systems to support IP-based phones. A traditional phone system that has been adapted to support a mix of phones is referred to as a hybrid system. What we'll refer to as first-generation IP-based phone systems utilize a proprietary protocol for communications, or one of the older voice standards. Examples of proprietary protocols are SCCP (Cisco), UNIStim (Nortel), and MiNet (Mitel). As with digital phones, proprietary protocols require vendor-specific phones. Session Initiated Protocol (SIP), H.323, and MGCP are examples of standards-based protocols. Phones that conform to standards are designed to work on many different phone systems.
Voicemail systems
Voicemail systems are an important part of any business phone system. These systems provide auto attendant functions, and the playing and recording of messages. The voicemail system can be thought of as the voice of the phone system.
When calling into a phone system, the caller will hear the main auto attendant, which provides the caller with a menu of choices. The auto attendant plays a recorded message and waits for the caller to enter DTMF tones selecting a menu option or dialing an extension. Newer advanced auto attendant systems have grown to include voice recognition for menu items or extension selection.
The voicemail system also handles the recording and playback of user greetings and voicemail messages. Many modern voicemail systems allow multiple greetings to be selected by the user for out-of-office or extended-leave situations so that the user doesn't need to keep re-recording his or her notifications.
Unified messaging systems are an extension of voicemail systems that allow users to have a single inbox combining voicemail, email, and faxes. A true unified system will integrate these systems at the server level such that when you open or delete voicemail on a computer, it is marked as read or deleted in the voicemail system. A simple version of unified communications involves SMTP forwarding of voicemail to an email, or requires a setup of client software that handles email integration on the user's computer.
Traditional voicemail systems are usually sold to customers with support for a certain number of ports. The ports control how many simultaneous voice sessions can occur between the phone system and the voicemail system. The system may be contained on a card in the system or on a separate server outside the phone system cabinet.
An important but seemingly simple responsibility of the voicemail system is to signify to users that they have messages waiting. This notification usually takes the form of a Message Waiting Indicator (MWI) light that is lit on handsets.
Call routing logic
The "brains of the operation" in the traditional phone system is the call routing logic. The routing logic is called different things by different vendors, but may be referred to as the call controller or call manager. Its job is to evaluate calls and direct them (referred to as switching) to where they need to go based on many different factors. These factors include, but are not limited to, what number was dialed, who dialed it, and what time of day it is.
Calling functions and features
There are hundreds of call routing functions and phone system features that have been developed over the years. The following are some of the more common call functions and features.
Call hold
With call hold, the user presses a button on his or her phone that places a caller into a mode such that neither party can hear each other. Often, music or an announcement is played while the party is on hold (Music on Hold, or MoH). In small key systems, users on other phones can pick up on a line that has been placed on hold. With PBXs, the call is usually retrieved on the same phone that the call was put on hold with.
Call park orbits
Call park orbits were designed for PBX systems where the concepts of phone lines to users don't exist. Putting a call into a park orbit is accomplished by transferring a call to a holding queue (orbit). That call can be retrieved on any phone by dialing a retrieval (also referred to as a pickup) code and the park orbit number.
Call pickup
Call pickup is the ability of one user to pick up another user's ringing phone. Often, permissions are required to do this function. This feature is typically accomplished by dialing a pickup code and the extension of the ringing phone.
Call transfer
Call transfer is the ability of a user to send a phone call to another extension on the phone system. There are two types of transfer: consultative and blind. In a consultative (also referred to as attended or supervised) transfer, the calling party confers with the party that it will transfer the call to before the call is transferred. In a blind (also referred to as unattended) transfer, the call is simply transferred to the selected extension.
Call forwarding
Call forwarding is a service that allows a user (or the phone system) to have a call redirected to another extension or number. The forwarding decision can be a strict choice to always forward, or it could be based on certain criteria such as whether the called party is busy, who is calling, time of day, and so on. Time of day forwarding is also referred to as "Time-based Follow-me/Find-me".
Speed dial
Speed dials in a traditional PBX are phone numbers that can be dialed in order to dial a more complicated number. For example, a user would dial 752 and the phone system would actually dial 18005555555. Most systems allow user-specified as well as system-wide speed dials.
Direct Station Selection/Busy Lamp Field
Direct Station Selection (DSS) can be thought of as a one-touch speed dial assigned to a key on a user's telephone. The user presses the button and the number assigned to the button is automatically dialed. When combined with information about an extension on the receiving end of the DSS, the feature is referred to as a Busy Lamp Field ( BLF, DSS/BLF or Presence). If the remote party is on the phone, a BLF will usually have a solid light on or near the button. If the remote party's phone is in a "Do Not Disturb" mode, (the phone rejects all calls) the light may blink.
Hunt groups
A hunt group is a collection of extensions that ring in a particular order when the hunt group number is dialed. The hunt group number is often referred to as the pilot number of the hunt group. Linear hunt groups always start ringing the first extension in the list and end ringing the last extension in the list. With a circular hunt group, the phone system remembers the last number that answered ringing and begins ringing on the next number in the list and when the end of the list is reached, it wraps around to the first number in the list again.
Automatic Call Distribution
Automatic Call Distribution (ACD) can be thought of as intelligent hunt groups. They allow phone system users (agents) to sign in and out of calling queues. Calls then ring agents based on different factors such as who is the first person in the ACD list, or which agent has been idle the longest. The ACD systems also allow other niceties such as wrap up time for agents after a call is completed.
Dial plans
The system dial plans provide the routing logic for inbound calls and outbound calls from the system. The dial plans evaluate the dialed numbers by looking for patterns of digits and directing calls to different destinations. It is up to the phone system designer to set up their dial plans based on their phone providers and the phone numbers they know their users will need to dial.
Intercom
The intercom function in a phone system allows a single user to dial another user's extension, makes the receiving user's phone automatically go "off-hook" in speaker phone mode, and allows the two parties to converse.
Paging
Paging is similar to intercom functionality, but it differs in one way. It is designed to allow a single user to broadcast a message to a group of other phones without the ability of the receiving phones to talk back to the caller.
Conferencing
A conference is a call between three or more parties. A conference may be a simple phone-based multi-party conversation, or may be hosted by a full-featured conference server. A simple phone-based conference requires a phone user to call multiple parties and establish the conference call. A conference server allows more parties, achieves finer-grained control by a conference moderator, and allows participants to come and go as they choose. A conference server will host many "rooms" where participants can meet. These conference rooms are often referred to as "Meet-Me" conferences.
sipX Enterprise Communications System overview
sipX Enterprise Communications System (sipXecs) is a highly scalable, enterprise-grade communications solution. It is a product of the independent, not for-profit, open source organization known as SIPFoundry. Leveraging standards and built in an open source environment, sipXecs offers dramatic cost savings, ease of use, and a degree of interoperability, functionality, and scalability that is not found in other systems.
It is without surprise that the sipXecs features mimic much of the well-defined functionality of a traditional phone system that users expect. The usual phone system cabinet is gone, and components of the system are separated and held together by network switching equipment.
The iPBX
The core of the phone system has always been the PBX and this is no different with sipXecs. The traditional PBX is now referred to as an iPBX or a Softswitch. This name is derived from the fact that the PBX functionality is accomplished in software running on a standard server. Since the software can run on a standard type of server, this computer can be as reliable as a customer demands and as fast as required for the number of users the system will support.
Ease of use and installation have been a fundamental founding principal of the sipXecs project. System administration and configuration is done using a web interface provided by a system service called the configuration server. The configuration server is a core component of the system, which ensures that data consistency is always maintained across all elements of the iPBX.
Technically, at the heart of the sipXecs iPBX is a Session Initiated Protocol (SIP) proxy. SIP is an Internet Engineering Task Force (IETF) standard protocol user for conducting interactive communications. SIP can be utilized for many forms of communications sessions, including voice, video, and chat. The SIP call signaling is independent from the media sessions it controls.
The sipXecs proxy can be thought of as a call router. Its job is to direct SIP calls through the system. The proxy itself does not handle any voice traffic (media). This is one of the reasons why sipXecs systems are so scalable as opposed to other IP phone systems that must process voice traffic within the iPBX.
The iPBX, as a whole, is a collection of 14 separate services running on a single or multiple Linux-based servers. These services are: sipxsupervisor, freeswitch, sipregistrar, sipstatus, sipxacd, sipxbridge, sipxcallresolver, sipxconfig-agent, sipxconfig, sipxivr, sipxpage, sipxpark, sipxpresence, sipXproxy, sipxrelay, sipxrls, and sipXvxml. These services interoperate to deliver all of the system functionality.
Gateways
The gateway provides communications system connectivity to the telecommunications providers. A gateway may be a physical device connecting a traditional type of phone circuit, as discussed earlier, or a software-based gateway providing connectivity to Internet Telephony Service Providers (ITSP). The quality of the gateway and the type of connectivity will determine the quality of the audio conversation with phones outside the phone system.
Telephones
One of the great advantages of a communications platform built on open standards is the incredible flexibility and the breadth of user peripherals available to customers. Hard phones (standard desk phones), softphones (software-based phones that run on desktop, laptop, or handheld computers), WiFi phones (run over a company's wireless network), SIP DECT phones (run over a DECT wireless network), and interfaces to traditional analog and digital phones are all available.
sipXecs features
sipXecs provides the features that businesses have grown to expect from their communications systems along with some additional functionality that's not possible in traditional PBXs. The feature list is constantly being refined and expanded as developers in the open source community keep adding new functionality.
Voicemail
sipXecs includes a simple yet complete voicemail system. Users can access voicemail through their phone, via a web browser, or receive their voicemail as email. Voicemail to email is a simple unified communications type with a twist. Included as part of the email are hyperlinks that allow the user to erase his or her voicemail from the voicemail server.
For the number of minutes of voicemail, administrators are only limited by the capacity of the storage in their servers. Additionally, there is no hard set limit for how many voice paths (ports) can be active to the voicemail server at one time. System speed is the only limiting factor.
sipXecs can optionally integrate with a Microsoft Exchange 2007 Unified Messaging Server for a fully unified messaging experience. The system administrator can also mix and match with some users on the internal voicemail system and some on Exchange.
Auto Attendant
The multilevel Auto Attendant service provides system-wide answering of incoming calls, dial by name abilities, automated transfer to local extensions, access to remote voicemail retrieval, and transfer to other auto attendants. The following screenshot shows the sipXconfig interface for modifying system Auto Attendants:
The number of auto attendants is limited only by the administrator's creativity and the callers' patience.
Music on Hold
There are multiple methods of supporting Music on Hold (MoH) on SIP-based phone systems. For SIP phones that can use it, sipXecs supports a standard as defined in an IETF draft written by Dale R. Worley of Nortel (http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-worley-service-example-01.html). This standard is dependent on the phone to transfer the call to a service that is playing the MoH, and then recall the caller when the caller is taken off hold. Presently, this method is known to be supported by Nortel, Polycom, and Snom phones.
For calls from an ITSP, the sipXbridge service can provide MoH, which allows any phone to have MoH capabilities without having to support the IETF draft.
Call park orbits
The sipXpark service allows users to park an active call to a park extension, and then later pick up that call from any phone by dialing a retrieve code and the park extension. While the call is parked, the caller will hear call park audio, which can be uploaded by the administrator. This following screenshot shows a typical Call Park Extension and its basic configuration elements:
Park orbits can be configured to allow single or multiple callers to be parked. If multiple callers are parked, they are retrieved in a first-in first-out (FIFO) order. An unlimited number of park orbits can be created.
Page groups
The sipXecs paging service (sipxpage) allows the system administrator to define multiple paging groups of phones to contact for paging. When a user dials the paging code followed by the paging group number, all the phones in the paging group go off-hook on speaker phone, a tone (which can be uploaded) is played, and then the user may broadcast their message. The following Paging Groups configuration screen allows the administrator to configure the paging dial prefix and define a group of phones that will go off-hook to play the pages:
At present, Polycom and LG Nortel phones will be automatically configured to support paging when added to a paging group. Other phones may be configured manually.
