Posts

SIP based Contact Center

Migrating to a SIP Contact Center

With every year, SIP is becoming more and more common in unified communication solutions in general, and contact center applications in particular, as companies increasingly recognize the benefits that an all-SIP environment can provide. Legacy contact centers have become expensive to maintain and upgrade and harder to integrate with new and high-value applications. Companies with limited in-house resources can especially benefit from SIP which can support a more dispersed work force including home agents or those working from remote locations.

The SIP based contact center allows companies to leverage new capabilities without pouring more resources into management or IT, infrastructure and applications. These capabilities can be deployed quickly, they are easy to deliver to remote agents and as the companies grow, the solutions can grow with them.

SIP based Contact Center

For many organizations, SIP is an integral part of an upgrade, while for others, SIP is part of a telecom cost reduction strategy.

Consider the following migration paths and best practices:

Step 1: Disconnect the PBX from Contact Center trunks

By disconnecting trunks from the PBX, calls can go directly into the contact center, enabling the introduction of new features not supported by the PBX. Data centers can be centralized, routing calls to dispersed contact centers and sending calls to agents that may be company-based, remotely-based or home-based.

Step 2: Computer Telephony Integration (CTI) Migration

Moving to SIP removes some major pain points that have limited contact center efficiency improvements in the past. In particular, it removes the dependency on the PBX. With traditional PBXs, the link between the PBX and the contact center is via a proprietary CTI link. If the CTI link does not support a certain function or does not provide the data necessary for a specific operation, nothing can be done to overcome the limitation. However, in a SIP environment the flexibility is significantly increased because calls can be directed to the contact center application directly.

Step 3: SIP trunking

Consolidation of telephony trunks into SIP trunks saves a considerable amount of money and is far more flexible and scalable. In addition to the estimated cost savings that can be achieved by using VoIP calls, SIP offers the ability to introduce a whole range of additional services to make the customer service operation more effective, ranging from high definition voice to video and more. Contact centers can save considerable expenses by cutting back on toll-free numbers, as VoIP enables click-to-call, which customers can initiate from their PCs or smartphones. Also, with domestic calling being free, VoIP provides another option for agents to make outbound calls to customers, allowing them to be more responsive or even proactive. In terms of enhancing the customer experience, SIP trunking also enables HD audio, providing a high quality call which can be a real differentiator for many companies.

The Key: Seamless Migration

A seamless migration from legacy infrastructures to SIP is key for organizations making the move, many of which are deeply invested in their legacy equipment. In moving to a SIP-based contact center, there is no need for “rip-and-replace” or discarding earlier investments. Customers can choose to convert to this architecture at their own pace and the SIP solution can grow in line with business needs.

Of course, an open architecture like SIP does have some pitfalls: there is no guarantee that two SIP devices will seamlessly operate together out of the box. Basic functions will work but enhanced functions may need to be tested first. AudioCodes provides a complete end-to-end solution consisting of gateways, SBCs, IP phones and other devices that have already been extensively tested and documented in the contact center environment to ensure full functionality out of the box, considerably reducing risk and professional service requirements in a SIP installation.

TCO Reduction

Ultimately, the result of the move to SIP is a significant reduction of TCO.  This is reflected in the considerable savings generated by a reduction of infrastructure costs including the consolidation of telephony trunking and the elimination of separate infrastructure at each location. By virtualizing the resources through the provision of centralized administration, enterprise-wide resources are better put to use, and the company benefits from the flexibility to support multi-channel interactions with customers and a distributed contact center structure which can consist of multiple sites, home agents and hosted services. Additionally, SIP future proofs new media and applications. All this leads to increased agent satisfaction and a better customer experience which also saves costs.

See what AudioCodes has to offer for your Contact Center.

VocaNOM in Amazon AWS Cloud

How Amazon AWS Scaled Up Our Business

For several years we have been in the process of enhancing our products to allow them to live in the cloud, a good example of this is the virtual SBC. In this context we have taken VocaNOM one step further and changed it from being a product to a cloud service running on Amazon AWS.

The Amazon team was pretty excited about this and conducted an interview with our VocaNOM Product Manager Yacov Tzadikov. More about the magic of VocaNOM below the clip.

VocaNOM in a nutshell

We all know what personal assistants are, Siri being one good example. Less common are personal assistants at the enterprise level. As an employee in an enterprise, not all of the enterprise information is stored on your mobile device and synced.

VocaNOM comes to solve a few fundamental issues:

  • How do I find contact details of a colleague who is not in my contacts?
  • How do I call this contact easily without starting to search my contacts when not really free to do so? (e.g. while driving)
  • How do I make sure my enterprise contacts are always in sync?

The scenario using VocaNOM is as follows:

  • You press a quick dial on your mobile or desk phone
  • You state the name of the person you are looking for and on which device to call him/her
  • The call is connected

This is as close to hands free/hassle free as it can get (that is until we have brain-controlled systems where you only need to think about the person you want to call).

No long search in the corporate directory or phone contact list and no driving while typing the name of a person (which is dangerous and rightfully illegal in many countries).

The idea behind VocaNOM is simple but can be realized only when you have a technological and product heritage as available at AudioCodes. The ingredients required to achieve this included:

  • Great and accurate speech recognition technology fully controlled by the company so we can modify and adapt the technology to run in any environment
  • An SBC that connects to any existing PBX and UC environment

All this was combined into a product that was installed on premise at enterprises. But we wanted more… We wanted to make the on-boarding of new customers as simple as possible. We wanted to make their buying decision risk free. We wanted to let people try it out instantly. The answer to this was to move VocaNOM to the cloud and offer it as a service.

Moving to Amazon AWS

The new architecture of VocaNOM as a service in the cloud can be viewed in the diagram below.

VocaNOM in Amazon AWS Cloud

In the Amazon cloud we have all the components required to run the VocaNOM service. These include the IVR and the Automatic Speech Recognition (ASR) SW as well as the web management interface. The VocaNOM system synchronizes with the company directory and stores contact information on Amazon RDS (data base).

Additionally, the AudioCodes cloud SBC takes care of passing the speech from the user to the ASR system for recognition and later to send the SIP instruction for connecting the call between the two users.

Since enterprise PBX environments vary including VoIP and TDM systems and since there is a need for a secured communication between the enterprise and the cloud in order to avoid fraud, there is a small enterprise SBC that the enterprise’s IT installs within minutes in order to make this VocaNOM magic work securely and in any environment.

Since this service is sold today both directly to enterprises and through service providers to their business customers, VocaNOM comes with a 3 level multi-tenancy management system to allow service providers to easily manage their customers.

By making VocaNOM a service in the cloud, we managed to significantly shorten the on-boarding process, making it a simple, risk free IT decision to try out the product. Since VocaNOM is addictive, making this service easily accessible created great momentum in the growth of this business and the number of customers using the product.

Although VocaNOM is great to use as it is today, the development team has a few cool rabbits in their hat soon to be pulled out, which will add more fun features to the service.

All this probably sounds great but you don’t need to believe me, try VocaNOM for free today and experience it yourself.

Classification

How Personal Can an SBC Get with You?

Understanding SBC User Classification

 [Post is better viewed on the blog Website]

 As I delve more into the nature of the SBC, I uncover additional layers of complexity that the SBC needs to address and solve. This returns me back to one of my earlier posts about the need for an SBC.

Taking a broader view makes me think about the role of standards, or more accurately, where their role ends and where the role of application specific implementation begins. This was taken to the extreme with WebRTC, something I touched upon in a post about WebRTC signaling and whether it should be standard or non-standard.

The reality is that also in “traditional” SIP communication there is a limited scope that standards can encompass. After all, the SBC wasn’t invented as a standard entity but rather as an entity that performs things in a different way than what the standards defined. It succeeded because it worked… it offered a solution for some of the major VoIP deployment roadblocks such as FW/NAT traversal. Real life experience proved that some things better stay in the application level, settling for only standardizing must-have functions, as was done correctly with WebRTC.

In this blog post I want to address one such application level functionality of the SBC. Basically, the question I wanted to answer was – “to what extent does an SBC need to take decisions based on who is the user participating in the session?”. The topic came up in one of my discussions with R&D and I decided that rather than enjoying this information by myself, I would share it on the blog.

To shed some more light on this topic, I turned to Ilan Avner. Ilan is SIP-SBC Group Leader and a VoIP Expert.

Q. To what level does the SBC take decisions based on personal user characteristics?

The identity of the user and the equipment from which he initiated the session are important factors in SBC decision process. There are SBCs that use layer 3 information for this process and don’t extend the analysis to the user level. We found this method of using a pre-defined profile based on IP address mapping to be insufficient for an enterprise environment where IP addresses of devices and users may change. Moreover, even though the analysis of the user and SIP message fields is far more complex, performing what we call “User Classification” is an indispensable part of the SBC decision process.

Classification

Q. You talked about the importance of User Classification. Can you shed some light on what exactly User Classification is and how it is used in the SBC decision process?

User Classification is a process in which users are grouped according to an array of parameters. When a SIP session is initiated and arrives at the SBC, on top of layer 3 classification there are 3 fundamental parameters of the session that help in the classification:

  • The type of remote SIP server – IP-PBX, Gateway, SBC, Media Server, Proxy, etc.
  • The device vendor – this is relevant both for clients and servers
  • SIP user information – this is specific information about the user itself, not the device. It can be about the group of which he is part, or about the organization or related policy

Q. What are the SBC use cases of User Classifications and for what type of decisions does the SBC use this information?

Information collected and the resulting classification of the user further helps in SBC decisions such as:

  • Routing and SIP message manipulations
  • SLA Enforcement – Call Admission Control (CAC), QoE, bandwidth management
  • Enforcing security policy
  • Overcoming SIP signaling mismatches (SIP interoperability)
  • Media functionality such as codec transcoding and FAX transcoding

 Q. Can you give some specific examples of how user classification is implemented in the AudioCodes SBC?

The AudioCodes SBC has this classification ability built-in its basic SIP processing. Each dialog request goes through a built-in classification process, the dialog can be classified either by layer 3 parameters or by any SIP layer parameters (using a dedicated classification table), once the SIP traffic is classified the dialog is tagged as belonging to a specific SIP group, this group is then used as an input to all of the dialog processing (Routing, Manipulations, CAC, Security, SIP signaling functionality, Media functionality…).

As part of the classification process our SBC looks at various parts of the SIP message. Here are a few examples:

  • Any SIP URI that appears in the SIP message (Request-URI\TO\FROM\P-Asserted\P-Preferred…)
  • A list of supported codecs and capabilities (e.g. FAX support)
  • Any vendor specific parameter (e.g. user agent or any X-Header)

Illustration of SBV user classification 

In the above diagram we see 4 different types of SIP user agents and the classification parameters each received by the SBC. This is of course an example, the actual classification is more complex and involves additional SIP message fields. The end result of this process is the tagging of each session and users associated with it, thus allowing for different SDP negotiation and SIP message exchange manipulation.

In conclusion

SBCs are required to perform complex decision processes per session and should, therefore, use every piece of information available including user specific data. This logic can’t be part of the standard but rather the application and therefore is part of the differentiation between SBCs available on the market.

SIP Trunk

The SBC: A VoIP Network’s Best Friend

[Post is better viewed on the blog Website]

The Move from TDM to SIP Trunking

SIP TrunkI recently participated in an interesting webinar hosted by NoJitter entitled Real World SIP Trunking Advice: How IT Managers Seize the Opportunity and Avoid the Pitfalls. The webinar focused on the increasingly popular trend to move to SIP Trunking from legacy TDM.  The webinar highlighted research by Forrester which pointed to the fact that while only some 25% of companies have moved over to SIP Trunking so far, the move to SIP Trunking is indeed the future trend and will increase in the coming years.  The move is inevitable as it will save businesses a considerable amount of money, including dramatic reductions in telephony costs by moving to VoIP. And the key ingredient to the success of the move over to SIP trunking is the Session Border Controller (SBC).

The Necessity of an SBC

Theoretically, SIP trunks can connect to the existing IP-PBX without the need for an SBC. However, not using an SBC can lead to a whole array of issues which need to be taken into consideration.  For example, SIP implementation variances can lead to interoperability issues across multivendor systems and service provider networks.  Delivering high voice quality by minimizing packet loss, jitter and latency are also issues that need to be handled. And finally, the vital issue of security must be taken into account as well as SIP trunks are exposed to security threats. Conventional firewalls are not designed to secure VoIP traffic from denial of service attacks or toll fraud.

All of these issues are handled by the basic functionality of the SBC which includes: Security (encompassing such features as providing a VoIP firewall, topology hiding, encryption, and protection from attacks such as denial of service and call fraud); Connectivity (including SIP normalization, NAT Traversal, voice mediation and transcoding, DTMF and Fax conversion); and SLA and Quality of Service. Additionally, the SBC ensures business continuity by minimizing potential service interruption due to call spikes, power outages, service failures, loss of connectivity and natural disasters.

(For more on the role of SBCs, see our previous post by Amir Zmora, Who Needs an SBC Anyway?)

SBCs Handle Unique Challenges Facing Large Enterprises

SBCs are indeed very powerful devices that provide a plethora of services to the enterprise or service provider on whose network they are deployed, and they play a major role in the move to SIP Trunking. This is especially true for large enterprises which have their own unique set of challenges that go beyond the basics, challenges that are also well met by the SBC.

Large enterprises tend to have several major data centers and many geographically dispersed branches. These branches many times have different PBXs, different technologies and different network hardware, and they all need to talk to each other.

These large enterprises will face challenges managing their VoIP networks. Here are some examples:

  • Different branches may be using equipment from different vendors, for example, from Cisco, Avaya, Microsoft Lync and others. Through mergers and acquisitions, large enterprises may have acquired different systems that are now incorporated into the larger network and have to be managed differently.
  • The organization may be going through a migration from one technology to another (moving from TDM to SIP Trunking, for example) but still needs to interoperate with its legacy equipment.
  • The enterprise cannot afford down-time on the network and must ensure the survivability of the network in the case of the loss of WAN connectivity to the Service Provider.
  • IT Administrators would ideally want to see all the alarms monitored on the network in a single location, aggregated and prioritized, rather than have to go out and get them from different systems.
  • Because large enterprises deploy complex networks with a number of SBCs and Gateways, sometimes with different PBXs and IP-PBXs in the various branches, they are faced with complex routing challenges for their VoIP networks.
  • And more…

(For more information on the opportunity of VoIP for small businesses, see our previous post by Itzik Feiglevitch, Small Businesses-Big Opportunity)

 A VoIP Network’s Best Friend

More and more IT administrators are recognizing the power and value of the SBC on their voice networks. In their March 2014 Enterprise Session Border Controllers Quarterly Worldwide and Regional Market Size and Forecasts: 4Q13 focused on the enterprise, Infonetics Research reported that 2013 SBC revenues rose 42% over the previous year and they projected revenues to continue to rise at around 12% annually through 2018. Infonetics states that the primary driver for growth for SBCs is the adoption of SIP trunking services (no surprise), and while most sales are currently in North America (76% of total sales in 2013), other regions are expected to post growth as well, especially in Europe, where the adoption of SIP trunking is accelerating.

Clearly, large enterprises with complex VoIP network deployments face considerable challenges. However, the SBC provides tremendous functionality that can address these challenges well. As the move to SIP Trunking continues to gain momentum, more and more IT Administrators are sure to discover that the SBC is their VoIP network’s best friend.

Image credit: Flickr user Christina Quinn. Modified by AudioCodes under Creative Commons licensing

Enterprise Mobility in the City of Gaudi

Enterprise Mobility in the City of Gaudi

[Post is better viewed on the blog Website]

Cloud based enterprise mobility suite by AudioCodes

February is a busy month for us. We are now in the midst of the Microsoft Lync Conference and Mobile World Congress 2014 is taking place next week.

Mobile World Congress is special for us this year as we are finalizing the move of our enterprise mobility suite to the cloud and enriching it with new functionality.

Enterprise Mobility in the City of Gaudi

 Image source: Wikimedia Commons

What is AudioCodes One Voice for Enterprise Mobility all about?

Our newly launched solution, AudioCodes One Voice for Enterprise Mobility, creates a complete integration of mobile UC with enterprise UC in a secured and managed manner. It enables business employees to communicate with their colleagues seamlessly from their smartphone devices by initiating VoIP calls over Wi-Fi and cellular data services, through almost any enterprise PBX or IP-PBX. The solution allows enterprises to improve collaboration between their employees through features such as advanced dialing, smart contacts, enhanced presence, instant messaging and one-number reach. Enterprises can also dramatically reduce their cellular communications charges when roaming or using their private network.

Also included in the newly launched solution suite is cloud-based voice dialer application. We developed an Automatic Speech Recognition (ASR) solution for the Interactive Voice Response (IVR) market. By using our voice activated name dialing technology, we allow callers to state the name of the person or department they wish to call and be automatically transferred to the requested party, thus, relieving the hassle of searching for phone numbers or waiting to speak to an operator. This is an advanced service that can easily be integrated with most of the existing PBXs and IPBXs deployed today on the market eliminating the need for replacing existing equipment.

The solution is ideal for users on the go, specifically for making business calls while driving. It will be much safer and efficient to use our voice for dialing rather than our hands (and more in-line with legal regulations in some countries).

We are getting great initial feedback from our partners and customers and we are looking forward to hearing your feedback as well. We invite you to meet with us at Mobile World Congress. We are located at Booth #9, Section #5E81 in Hall 5. Just send me an email with your preferred time for getting together.

Read more about our new solution at:  http://www.audiocodes.com/solutions/enterprise-mobility or view the press release.

 

Image: AudioCodes SBC Configuration Wizard

Making SBC Configuration Human

When I visited a 777 cockpit for the first time, what struck me most was all the buttons. I thought to myself, how on earth do the pilots know what to do with them all?

Looking at an SBC configuration reminds me of that same experience and over the years I played aroundwith quite a few SBCs of the SBCs out on the market.

Putting things into perspective, a typical SBC user manual is a few hundred pages long. A typical vendor’s beginner SBC course would run three days or more.

In light of this reality, one of the first questions an experienced customer would ask when considering an SBC would be, “just how complex is the SBC to configure?”

The perception of complexity is well rooted in reality and for good reason. It is not that SBC vendors lack UX (User Experience) knowledge or capabilities. The complexity is derived from the flexibility of the different VoIP standards, which means that every vendor can implement the standards in a different way. An advanced SBC is expected to deal with all of this complexity and interwork between different parts of the network on multiple layers, including SIP, media and IP. The SBC needs to be able to classify groups of users according to multiple attributes, to maintain access lists, manage security, routing and more.

Complexity has its price

The implications of SBC complexity are serious. For one, such complexity raises the cost of installation as technicians need to spend more time on site; it increases the chance of misconfiguration resulting in communication errors and increased support costs. Overall, the complexity of an SBC constitutes a hurdle in the transition to SIP trunking.

But does it have to be that complex?

Consider the following:

  • As it does elsewhere, the 80/20 rule holds true for SBCs as well. 80 percent of SBC customers only use 20 percent of the SBC’s configuration options.
  • The variance between similar deployments of different customers is relatively small. By ‘similar deployments’ I refer to a setup which involves certain kinds of PBX (and software releases), a SBC, and a service provider’s SIP trunk service.

The bottom line is that when looking at two different customers that have similar setups, each customer’s configuration will only differ marginally. The difference would usually include IP addresses and other layer 3 to 4 settings, number manipulation rules, authentication passwords and several additional parameters.

Taking the wizard route

A configuration wizard is a well-known user interface concept common in desktops and web applications. The wizard is used to get the user up and running quickly in just a few steps, leaving the advanced application configuration to a later stage using a parameter centric GUI.Image: AudioCodes SBC Configuration Wizard

The 80/20 rule and the typical similarity between deployments makes the wizard approach a perfect fit for an SBC configuration.

At AudioCodes, we adopted this approach and have developed an SBC configuration wizard application.

Starting with the deployment similarities, we defined “interoperability templates” which in practice is a configuration set which relates to a certain kind of PBX and a service provider’s SIP trunk service. (It can also relate to hosted services and PBX to PBX setups.)

The user configuring the SBC is asked to insert the PBX model, service provider and SBC types into the wizard. After that, all that’s left to do is to provision a few more parameters.

AudioCodes routinely updates its interoperability templates database, which currently comprises over 60 different templates! Every time the SBC wizard is used, it connects to the AudioCodes cloud database and downloads the latest interoperability templates.

After filling in the wizard screens, an SBC configuration file is created. The file can be sent directly to the SBC from the wizard.

In some cases, the configuration will now be complete, leaving the SBC in an operational mode. In other cases, the user would already be able to send calls through the SBC, but would still need to complete the installation by configuring a few additional parameters on the device web GUI.

The end result achieved through using the SBC configuration wizard is a substantial reduction in time and complexity in configuring an AudioCodes SBC. In most cases, it takes no more than five minutes to get initial calls going.

If you, too, have felt “lost in configuration”, where finding the right knob to turn is like finding a needle in a haystack, we would like to hear about your experience and how you navigated through.