Fonality has announced its latest enterprise-grade release, PBXtra Call Center Edition. TNC.net also has an interview with Fonality’s CEO.

Fonality today released their latest version of PBXtra Call Center Edition v3.5, an Asterisk-based IP-PBX, and added some interesting new call center features. For instance, PBXtra Call Center Edition has a new feature that lets remote call center agent’s receive phone calls using any type of phone – VoIP phone, analog phone, cell phone. etc. PBXtra will call the agent when it’s his/her turn to answer a call in the ACD queue. This is similar to DISA (Direct Inward System Access) that call centers have used over the years to allow remote agents to remotely partipate in ACD queues. The problem with using DISA is that it required the agent to place a potentially long-distance call to the corporate PBX, logon with DTMF access codes, and remain connected to the switch/PBX. This not only racked up PSTN per-minute charge, it also uses valuable port resources on the PBX.

This edition of PBXtra includes special features meant for the call center market. For one, as mentioned in the quote, PBXtra call center edition lets call center agents receive calls through any terminal, be it analog, VoIP, or mobile-based. However, while the traditional Direct Inward System Access (DISA) may require potentially expensive long-distance calls, PBXtra’s solution uses VoIP, and therefore can get remote agents connected at a lower cost. PBXtra also only connects to a remote agent if a call is routed to his terminal. For instance, if an agent doesn’t answer a call, it is then routed to the next available agent. After 8 unsuccessful calls, that agent is then automatically logged off the system.

This edition also includes an optional HUD (heads-up display) Agent, which allows text messages to be exchanged across agents and with a supervisor. This is particularly useful when supervisors need to communicate with agents, especially when the latter needs help. Supervisors can also barge-in on calls.

PBXtra also allows routing to off-site offices during overflow situations. This means if all agents on a given site are currently busy or unable to take calls, the system will route a call to other branch offices.

In summary, what’s new in PBXtra Call Center is the ability to manage call queues across multiple branch offices, and support for home-based workers and agents on cell phones. Also new is the web-based reporting capabilities which deliver real-time reports of the call queues. PBXtra Call Center is optionally available with HUD Agent, a universal contact management application that provides company-wide visibility and interaction, and includes secure chat and employee presence management for an additional $1000.

The PBXtra Call Center edition costs US$ 2,995. The optional advanced HUD costs an additional $1,000.

I came across an interesting article on voip-news.com. It’s about this new threat and scourge to the community called spam over Internet telephony (or SPIT for short). If SPAM is for email, SPIT is for VoIP. SPIT are basically unsolicited voicemails sent over VoIP networks.

Compared to email spam, SPIT might be a bigger problem to deal with. While emails are only a few kilobytes apiece, voice messages can take up several megabytes each. Multiply that by thousands, and you have potential bandwidth problems. This can potentially increase your bandwidth bills several times over!

And then there’s the problem of volume. Take for instance email spam. In 2002, it was reported that spam constituted only 17% of worldwide email traffic. Two years later, it went up to 93% (according to Wired). If spam over VoIP grows that fast, then bulk of Internet traffic might just turn out to be junk messages, again considering the size of each message.

SPIT calls are characterized by being–of course–unsolicited, and by being sent by machines instead of humans. Just like spam-bots sent by millions of zombie computers around the world, spam Voice messages are sent by software.

Therefore, among the several means of fighting spam calls is the usual turing test, which will help determine if the caller is man or machine. The turing test is basically a challenge, that sees if the remote party is able to respond like a human–and for this purpose, tests answerable only with human intelligence are used. This may entail asking callers to input a random set of numbers before being let through, or such other methods.

Another means of combating SPIT is whitelisting, meaning only calls from known parties are accepted and let through without question. However, caller ID can be spoofed, so this might not be effective in such situations.

Other means include software and heuristics–much like virus-scanning. Software would analyze a caller’s voice patterns.

It might be comforting to know that SPIT is not as common in the Americas as it is to other countries like Japan, where use of VoIP and data-rich mobile telephony are more prevalent. Still, it’s a good idea to secure oneself from the possibility of attack in the future.

In telephony, the phenomenon known as “echo” happens when a person hears what he has just said a few milliseconds after speaking. This can be experienced by either one or both parties. This issue seems to affect VoIP users more often than not, and the effect can range from irritating to unacceptable.

This echo is essentially feedback of one’s own voice coming from the telephone network. This feedback usually helps the person on the telephone know that the network is picking up his voice. However, if there is latency from anywhere between the terminal and the local exchange, this feedback will come in some time after speaking, and this could cause confusion.

There are several causes of echo in an Asterisk installation. First to check is your PSTN card, particularly whether its loadzone is correctly set. For instance, if your PSTN card is set to FCC (standard for US), but you’re in a UK line, then you are likely to experience harsh echo. You will therefore have to switch to UK mode.

Second, the connection from your gateway to the local exchange, or the connection of your called party to his own local exchange might be improperly balanced. This way, some of the signals transmitted are reflected back, therefore causing echo. This can be caused, among other things, by wet or damaged telephone cables, use of untwisted telephone wire on either end, or bridge taps. Another reason may be the analog handset used on the local line. Also, the use of speakerphones by the called party, could be a reason for echo (and this is further amplified by latency).

Solutions

There are basically three ways of dealing with echo. First is by eliminating the echo at the source, particularly by ensuring that all hybrids (connections from your VoIP gateway to the local exchange) are balanced. This is only theoretical, though. In practice, even balanced hybrids are likely to experience some echo.

Echo suppression is a solution used in earlier intercontinental calls. This method turns off transmission whenever a person stops talking. This is not useful, though, when both parties are talking simultaneously.

Lastly, echo cancellation uses a mathematical approach to removing echo from the signal. This essentially analyzes the signal that is transmitted when a person speaks, and subtracts the exact negative from any incoming signal if it arrives after a pre-set number of milliseconds. Therefore, echo is removed.

Calling people across time zones might prove to be inconveniencing to the receiving party, especially if it’s late at night or very early in the morning. Before, this wasn’t such a big issue, since you would know the time zone in the country of the person you’re calling. But with the advent of global roaming, you might be calling your neighbor’s mobile number, but he might be at the other side of the globe (and most likely asleep).

This is also an issue with VoIP, especially since VoIP clients/terminals do not really “reside” in a single country or time zone, and are most likely to be portable. So that same neighbor might be subscribed to a VoIP service, and he plugged in his phone onto his company’s regional office at the other side of the globe. Since the identity of that VoIP terminal is the same, then people calling in would still reach that particular terminal, regardless of location.

Linuxjournal has an article on how to make Asterisk redirect inbound callers to a message informing them that they are calling at inconvenient hours (and redirect to voicemail).

The system I built on top of Asterisk to handle this feature has two major parts. The key to the system is maintaining a time-zone offset from the time in London. (My code implements offsets only of whole hours, though it could be extended to use either half or quarter hours.) When a device first connects to Asterisk, its IP address is used to guess the location and, therefore, the time offset. After the offset is programmed into the system, incoming calls are then checked against the time at the remote location. Before the phone is allowed to ring, the time at the remote location is checked, and callers can be warned if they are trying to complete a call at an inconvenient time.

The system, built on top of Asterisk, has two steps. First is the time zone estimation. Second is confirming the estimated time (with user input). Third is alerting callers that they’re calling at an inconvenient time.

The first step involves estimating the time zone of a terminal once it connects to the Asterisk gateway. This can be done by approximation from the IP address used by the terminal. While Asterisk cannot estimate the time zone directly from the IP address, the system uses the Asterisk Gateway Interface to allow Asterisk to pass on data to an external program, execute computations on that external program, and then get results back as Asterisk channel variables.

The second step is asking the user to confirm the time zone of his current location by dialling in the current time and how long he expects to stay at that location.

Once the procedure is complete, calls will then first be screened to check if the terminal is still connected in a location where it’s night time. Asterisk will then silence the ringing, but this can be overridden either manually or by caller ID.

Do check out the linuxjournal article for a more detailed explanation of the procedures involved.