Posted on

Which Telephony Interface for your Solution: VoIP Gateway VS PCI card?

What is your PBX or CTI solution without an interface to the outside world. One can use VoIP but there are still a lot of systems going the traditional route and connecting to a Telco either via Analog (POTS) or a T1/PRI/E1.  With Asterisk the two main solutions to do this are an internal PCI card or an external Gateway device. Both options will make and receive calls from the telco but which one is better?

I’ll cut to the chase and say PCI cards should not be recommended for High Availability solutions. They can still have their place in a system without HA and where costs are a major factor, but the decision to use them should be made with their limitations in mind.

Using a Gateway device, such as Patton or Audiocodes, provides the following benefits over an internal card:

  • Multiple telephony servers can connect to a single gateway. Which is important for the next two items.
  • With multiple servers connected to a single gateway in a HA solution calls will be routed to the active server(s).
  • Load balancing done at the gateway level in a high volume centers to distributed calls across servers.
  • Independence from a single server. If a specific server needs to be rebooted or taken offline for maintenance a gateway will keep working.
  • Location of telco demarc can be independant of telephony system. This can be in a different room, floor, building or even country. Just be careful of lag causing issues. But given the proper connections can allow moving the IP PBX system into the cloud while still supporting traditional telco trunks.
  • In a mixed trunk environment of VoIP and traditional telco connections the Gateway can abstract this so the IP PBX’s configuration is similar for all trunks.
  • Scaling up only requires adding a new gateway and a configuration change to the telephony system which minimizes downtime and risk.  Mainly due to avoiding the need to open the system to install new cards.

Considering the above it is hard to see the case for a PCI card, especially in an HA solution.  They may still have their place elsewhere but I’ll be recommending a VoIP Gateway going forward.

Posted on

SIP Registration Timeout Settings for High Availability

In setting up a high available telephony system most worry about the back end and ensure it functions as they would expect and require.  However one highly visible user issue I have seen is a misconfiguration of the connected SIP phones in regards to the registration timeouts.  When these are very high on your SIP phone then it may not notice a service has moved (via IP/DNS/etc changes) due to a HA switchover and can potentially miss incoming calls until it does.  Typically an outgoing call attempt will work or at the very least cause a registration attempt to the new server the service has moved to.

For example take a look at Aastra, their defaults in a few models I’ve seen are at a half hour for a failed registration.

aastra-default-configuration-reg-failed-retry

If the failed registration timeout is half an hour and the phone attempts to re-register and fails your phone will show an error or unregistered for the next half hour.  This can happen in the cases where the registration comes in as a box is failing or a failover happened and the configuration is being written/updated due to the switchover process.  More reasonable set of values are shown in the following.

aastra-configuration-reg-failed-retry

In this one I’ve lowered the registration failed retry and also the timeout retry timers.  These will make the SIP phone resolve the registration issue quicker by retrying more often than the defaults.  They could be lower depending on the situation.

One precaution before everyone sets these very low.  These settings should be set appropriately when the SIP phone is off-site and there are protections, for example Fail2Ban, in place to block brute force attacks.  In these cases where the SIP phone is on an app on a mobile device this failed registration timeout should be set high enough to not trigger a lockout of a valid device.  If the devices are in-house or IPs can be whitelisted then the values can be lower without worry.

Posted on

Rightsizing your Telephony System from the Beginning

A number of common questions come up when purchasing telephony systems. One of the most important which affects costing the system is the expected usage in terms of number of users, ports and active calls. Knowing current needs is relatively straight forward especially for an existing business. However the real issue is businesses are not static and you want your new ACD/PBX system to be able to grow with your organization.

Obviously one can throw money at the issue up front and spec out the system for the projected size required in the future. However the better option is to choose a solution that can scale as your business grows without the need to replace the full system.

We find some systems have a large hardware cost upfront and limit usage via licensing so later expansion is done via purchasing new licenses to unlock the hardware already paid for. The issue here is the initial investment is large and compromises are often made to fit within the current budget which limit future growth on the system.

Two better alternatives are:

  1. Purchasing a system which meets your needs for the near term which can scale properly to meet the demands of the business well into the future.  The Q-Suite telephony platform accomplishes this by having the built-in ability of adding additional asterisk servers and web servers to an existing installation to scale to meet the needs of a business as it grows.  Recently the option of monthly licensing has been offered to save even further on initial costs.
  2. Using a Cloud based ACD/PBX System. This lets a provider worry about hardware upgrades, trunks, etc and allows growth in smaller increments.  Look at the hosted provider VitalVox where your role is only to configure and manage the users, campaign, queues, and other features of your ACD/PBX system.
Posted on

The Differences in Call Survival and Call Recovery

While investigating High Availability (HA) in CTI and PBX systems you will often find mention of Call Recovery. Another term you run into is Call Survival, which is often used interchangeably with Call Recovery incorrectly. This is because each is a different approach to solving a problem. The problem being a failure which would interrupt the calls of a system.

With Call Survival when a failure happens the caller and callee do not have to take action to continue their call as it survives the failure. At a high level this is done by reacting to the failure quickly and re-routing the audio path around the failure.

With Call Recovery when a failure happens the recovery is different depending on the system. Sometimes the caller will need to initiate the redial the callee or it could be an automated process but the callee still have to answer this new call.

From a user perspective the better option is Call Survival as they may only experience a momentary interruption in their audio as the path is rerouted around the failure instead of having to re-initiate a call to recovery it.

The Q-Suite platform supports Call Survival with the help of the Overseer Watchdog providing HA for other services in addition to being one part of the Call Survival solution.

Posted on

Contact Center ACD interface through Asterisk Manager Interface (AMI)

Large contact center installations with many concurrent users will scale to multiple Asterisk servers. This is the norm when building out a multi-tenant contact center or PBX roll out. With the growing popularity of Asterisk, it is being adopted for special mission critical applications with large concurrent users. In all such applications, the call center ACD plays a vital roll in managing queues and users. It routes the calls in the queues to the appropriate user console based on skills based routing and queue prioritization.

For more dynamic applications, the console application would want to have the real-time status information of all the calls in the queues. This data provides an opportunity to build additional powerful logic in the user consoles to better manage the calls. Such user consoles for customer service representatives and supervisors can empower them to intervene and handle calls based on the business rules of the organization.

A contact center ACD will manage multiple Asterisk telephony servers in a cluster through the Asterisk Manager Interface. Console applications can have continuous feed of the dynamic channel status information from all the incoming and outgoing calls handled by the call center ACD, by incorporating a listener in the console software. With adequate filters, this listener can be tuned to feed data to a versatile call handling logic, taking advantage of the real-time state information of all the channels, queues and users of the call center software.

Posted on

Features and trends dictating Multi-tenant Cloud services using Asterisk telephony

The global forecast of the Unified Communications market as a service is astounding. Predominant delivery of this service will be through Cloud based installations offering managed multi-tenant PBX and contact center ACD functionality. Asterisk PBX, the world’s leading  telephony engine, is  a complete platform for communications  that can fulfill the role of a soft-switch, a protocol gateway, a media server, and a VoIP gateway. With a world-wide following, it exercises considerable influence over the trends in the multi-tenant Cloud offering of PBX and call center services.

From its humble beginning as a hybrid PBX, it has risen to a position of consequence with serious implications for the legacy technology platforms. By virtue of being one of the most powerful telephony platforms with an extensive ecosystem, Asterisk offers functionality unmatched by most of its PBX peers.

Cloud based multi-tenant platforms for Asterisk can scale to multiple Asterisk servers with an external ACD, taking effective control of the switching through the Asterisk Manager Interface (AMI) available for individual servers. Powerful multi-tenant contact center ACD software for Asterisk work in a similar way.

The work-flow requirements for Unified Communications is a blend of inbound, outbound and PBX functionality. The PBX functionality includes everything from auto-attendant, find-me-follow-me, to advanced call routing on an individual basis. Organization require conferencing capabilities, email to voice-mail functions and a host of features like virtual cloud extensions, call accounting, ring groups, and ACD (Automatic Call Distribution) from the PBX.

Inbound call center ACD features include queues driven by skills based routing, powerful IVR, call routing, and call distribution. Queues have skills association and calls are routed to the appropriate staff available at the time. The ACD provides powerful real-time stats. Outbound workflow has changed dramatically in the last decade. From mass dialing, it has become selective dialing driven by effective CRM. The integration to CRM packages like Salesforce, Netsuite and Microsoft Dynamics provide visibility into the life cycle of leads.

Most Cloud multi-tenant PBX installation achieve greater marketability by offering call center functionality along with the PBX. A multi-tenant contact center software will be incomplete without offering full function PBX. The user-interface of a good Unified Communications system should blend inbound, outbound and PBX functions.

Posted on

ACD Inter-Operability with PBX switches simplifies remote and at-home agent setup

In many organizational setup, phone system is in place well before anything else. If a decision is made later to add customer service or support operations internally, it involves setting a full function contact center ACD.  This ACD will handle among other things, all the IVR (Interactive Voice Response), Queues, Skills based Routing, time of the day scheduling and associated call center activities for the planned customer service or support. Once an enterprise level call center software is identified based on functionality, its inter-operability with the existing office PBX will determine if the call center agents can also be a part of the same extension schema for uniformity within the organization.

Continue reading “ACD Inter-Operability with PBX switches simplifies remote and at-home agent setup”