There are many virtual PBX offerings on the market, but they are typically restricted to a certain set of standard VoIP functionality, such as call forwarding, ring groups, voice mail, and so on. In some occasions, this standard set is insufficient, and the customer needs a "smarter" solution.
VOXSERV is a system integration service for planning, engineering, setting up, and support for custom, tailored IP telephony solutions for various business needs.
Most of our solutions are using FreeSWITCH software. FreeSWITCH is a free, open-source IP telephony platform, offering a great deal of integration and customization possibilities.
Our virtual PBX are usually hosted in the cloud at a selected hosting partners, but can also be hosted at the customer facilities.
The following sections describe various business needs and scenarios that have been implemented for our customers.
It is quite common that a business person or a lawyer needs a virtual personal assistant which would look up their contacts and calendar and make decisions if the incoming call can be answered or declined. The following scenario describes a software system that helps the user manage their time and keep connected for important communication.
The user wants to manage their time efficiently, and to accept the calls only when there's time. Also there's a number of VIP contacts who are privileged to call even if the user is occupied. The user represents multiple companies, each company having a separate DID number. So, it is important to know which DID was called, and also to use a corresponding caller ID when calling out. If the user is unavailable, the caller should receive a voice prompt in one of 3 languages, telling when the user is going to be available next time. In addition, the user has multiple endpoint devices (local GSM mobile, built-in mobile in the car, a SIP phone in the office, and a foreign GSM number for traveling abroad). Thus, the virtual secretary should also implement a "follow-me" concept and forward inbound calls to the selected group of endpoints.
The user's availability depends on a number of criteria: normal working hours, vacations and bank holidays, and planned meetings. Also the user needs to set their availability status for an immediate short-term absence. In addition, the system should allow only one call at a time for the user, in any direction.
The virtual secretary is implemented as a set of Perl scripts that are executed from FreeSWITCH dialplan. The user's presence and contact list are imported from Google Calendar and Google Contacts respectively. A local MySQL database stores the contacts and calendar information for quick lookup during the call. Each contact belongs to a number of groups in Google Contacts. This membership determines various properties of a contact: which company's client it is, if it's a VIP or a blacklisted person, and which language is preferred.
Upon receiving an inbound call, the virtual assistant looks up if it's a known caller, what's the preferred language, and if the user is available. In case of unavailability, an automatic prompt tells when it's best to call the user next time. If the user is available for a call, the PBX performs a group call on the user's phone numbers. As soon as the call is picked up, the user hears a prompt telling which company's DID was called, what's the preferred language, and if it's a VIP contact. In addition, the original caller ID is preserved, so the user can see who's calling. The user has the possibility to accept or reject the call by pressing a digit or hanging up. In case of a rejected call, the caller receives a voice prompt explaining what time it's better to call.
The user has a number of endpoint groups (local GSM and SIP numbers, foreign-country GSM numbers, and a SIP account on the smartphone). Selection of a current endpoint group, as well as the available/unavailable status, is managed by an IVR and a web application. There are also short-dial codes for the SIP clients to switch the status quickly.
In order to make outbound calls from the company's DID, a call-through number is set up. After dialing it, the user is prompted for the destination number. The destination is looked up against the contact database, and if found, the outbound call is placed from a respective DID number. Otherwise, the user is prompted to select which company's caller ID to use. A typical calling-card program can be used on a smartphone to simplify the dialing.
Missed calls are indicated in the same web application which is used for switching the status. Also if a call from a VIP contact is missed, an SMS is sent to the particular GSM number determined by the current endpoint group.
A hotline service is set up for technical support, and the requirement is not to lose the call even if the current on-call engineer is not answering.
The PBX stores the information about the current on-call engineer in a persistent database. There is also an IVR which allows the engineer to switch the current on-call duty to themselves or to a colleague. The IVR is protected with PIN for calls from PSTN, and does not require a PIN for internal SIP calls.
Upon receiving a call on the hotline number, the PBX asks for the customer PIN. Several such customers can have different PINs, and the system would differentiate them when opening a new trouble ticket.
After PIN authentication, the call is routed to all known endpoints for the current on-call engineer (SIP clients and PSTN numbers). On mobile numbers, the engineer hears a prompt "Press 1 to answer the call", and the call is connected only after the digit 1 is pressed. This protects the hotline calls from being routed to an engineer's voice mailbox.
If the engineer is not answering, the caller is prompted to record a voice message. This message is then automatically forwarded to the ticketing system. The ticketing system will send SMS messages to all support engineers every 15 minutes until the ticket is taken into ownership.
In this scenario, there is only one on-call person at any given time. It is also possible to set up some more complex routing, with simultaneous calls to mobile and SIP numbers of several people. Also different groups of support engineers can be selected, based on which customer has called.
The user needs a conference bridge which is reachable from different countries at local call cost, and with a possibility to connect from any Skype account.
FreeSWITCH supports many various options for audio conferencing, and the following scenario is one of the possible ways to oset up a conference bridge.
When a user calls to the conference bridge, they are prompted to enter a conference room ID. The PBX supports multiple conference rooms (for example, one per employee), and guest access is defined by a random 4-digit number. The guests have to wait until the moderator logs in and opens the bridge. The moderator uses the same access phone number, but enters a different room ID. Then the moderator is also asked for a PIN.
The conference bridge can have multiple PSTN numbers for incoming calls from different countries. Any worldwide SIP provider which supports multiple suimultaneous channels is suitable for this.
Also the bridge may have an INUM number, and those numbers are routed from many regional telephony providers. Also there are numerous local access gateways in every part of the world.
American toll-free numbers (1-800) can be called from any Skype account, including those with zero credit. The conference bridge owner needs to take over the costs for incoming calls.
The conference calls can also be automatically recorded, and the users will hear a warning message in this case before starting the conference. The moderator may convert the recordings to MP3 format and share with the participants. Old recordings can be automatically deleted after a certain period of time.
Automatic call distributor
FreeSWITCH is the perfect platform for call center automation and building an ACD service. Built-in IVR engine allows to collect important information from the caller before adding the call to the queue. The queue handling can be organized by a standard FreeSWITCH module or by a custom script. Also the ACD can be integrated with the agent desktop applications, for example, to automatically display the customer-related information.
A feature which is very rare in today's call centers can be easily implemented in FreeSWITCH: if all the agents are busy, the system can take the caller's number, ask the caller if this number is correct (or prompt to enter an alternative number), and tell that an agent would call them as soon as possible. With this simple feature, the caller's frustration is minimized, and the agents' productivity can be increased. Also the system consumes less simultaneous voice channels, which leads to lower telephony costs.
SIP gateway for CUCM
Cisco Unified Communications Manager (CUCM) is often used as an enterprise telephony system, alongside with other Cisco software products, such as CUPS and Unity Connection. In most installations it is not exposed to the public Internet because of security reasons. Also Cisco softphones (IP Communicator, CUPC, Jabber) are not supposed to work over public Internet, especialially that CUPC and Jabber can be configured to authenticate against the corporate LDAP service.
Some users need to be part of the enterprise IP-telephony system, but to be able to call from outside of the office. If they use a Cisco softphone over a VPN connection, the voice quality usually suffers from high jitter, because the external routers cannot identify the voice packets within the encrypted VPN traffic flow and cannot apply any QoS rules.
A FreeSWITCH server (or a pair of servers in a failover cluster) can be installed in the DMZ and assigned a dedicated public IP address. It is important to avoid any NAT translation for voice traffic for this server for Internet and internal SIP peers.
The external SIP users would then register securely on this gateway, and their accounts would be independent from the corporate Active Directory. Their extensions in the CUCM dial plan are assigned to route patterns instead of directory numbers, and routed to the SIP trunks towards the FreeSWITCH server. Such users cannot be part of CUCM hunt lists, but they are readily available for the rest of the features, such as voicemail and local extension dialing.
In addition to handling the Internet SIP users and call routing, the FreeSWITCH server is the perfect place for media adaptation: while internal enterprise traffic is usually using G.711 codec, it is desirable to use Internet-optimized codecs for external users, such as Speex or iLBC. FreeSWITCH can perform the needed transcoding and provide the external users a choice of codecs for broader compatibility with various SIP clients. Optionally the SIP voice traffic can also be encrypted by means of ZRTP.
Automated voice quality assurance
A Quality Assurance service is built for a customer, in order to test and monitor end-to-end voice quality in their telephony inifrastructure.
VoIP calls from remote SIP servers and from PSTN providers are terminated on the QA server, and received audio stream is recorded and compared with the original test sound. Sevana's AQuA software is used for comparing the audio files and calculating the similarity and MOS scores. The results are stored in a database and sent to monitoring systems.
Technical details are available in this blog post.
VoIP trunk test probes
VoIP testing probes are set up for an ITSP to test business SIP trunks at customer locations. Each probe is a small Linux appliance with LTE modem and three Gigabit Ethernet interfaces. The LTE connection is used for managing the probe remotely via OpenVPN. One of the GE ports is dedicated for the customer LAN, and is attached to an LXC container, providing complete logical isolation of management traffic from the customer network. Another GE port is for the field technician's notebook, so that he or she can get a DHCP address and access the probe's GUI for performing the tests. The GUI is also available via OpenVPN from the management server, so the presence of the field technician is optional.
Once the probe is connected to the customer LAN, the test operator configures the container with IP addressing and SIP trunk parameters via the Web GUI. As soon as the container is up and running and the SIP connection is alive, the operator can initiate a number of tests. For the tests that need the operator's feedback, the operator enters success or failure status, and a comment describing the issue in case of a failure. The probe then saves the test protocol and full packet captures to the management server.
Most common tests are: a) echo tests: either the probe initiates a call to the operator, or the operator dials the probe, and the operator should hear his or her own voice to verify bidirectional voice communication; b) hangup tests: either of the sides hangs up the call, and the test verifies that the call is properly terminated on the opposite side. Also the probe reports the Caller ID for received calls, and the operator verifies the Caller ID for the calls that the probe originates.
The test configuration GUI is flexible to adapt for various use cases. First it prompts the operator to choose a configuration profile. Each profile corresponds to a separate instance of FreeSWITCH configuration, and it also defines QoS settings. For example, there may be several profiles, each for a specific product offering by the ITSP. Once the profile is selected, the GUI prompts to enter the test configuration parameters, such as the LAN address and gateway, SIP transport options, and the PSTN numbers of the operator and the probe. Once the configuration is applied, the probe performs a number of health checks: configuration completeness, network reachability, and SIP trunk status.
In addition to operator-assisted tests, the probe can be set up to perform long-term automatic testing. For example, the audio quality can be analyzed by specialized software.