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

Who-needs-an-SBC-Anyway-Thumbnail

Who Needs an SBC Anyway?

[Post is better viewed on the blog Website]

In the early days of SIP, I was working on VoIP protocol stacks at Radvision. As part my role there I used to attend many of the IETF meetings and SIPit interoperability events. The standards where the holy grail and we were a bit naïve in assuming that everyone would be implementing the standard and nothing but the standard…and networks and products would interconnect easily.

The SBCs Come to life

In those days, almost 15 years ago, new startups that focused on something they called a Session Border Controller (SBC) were coming to life. Later down the road of VoIP deployment, more established companies adopted this concept.

I remember a panel at one of the VON shows in which I came out against this trend. At the end of the day, I said, every single SBC function is handled by the standards. As long as the VoIP community will follow the standards, life will be good and simple.

Reality check

I guess it is needless to say that the world of VoIP is more complex than simply implementing the standard. The reality is that networks and products usually don’t interwork without a special effort to make this interworking possible. There are 2 fundamental reasons for this:

  • Standards are complex, very detailed with multiple options, and many times companies interpret them differently
  • Companies want to add their special secret sauce into their products and sometimes, due to technical or commercial reasons, they implement some of the functionalities in a proprietary manner

Regardless of the reasons this is the reality. The naïve position of the past didn’t pass the reality check of real life.

Who-needs-an-SBC-Anyway

The business communications angle

VoIP is deployed in many enterprises and service providers’ networks, yet there are still many enterprises and SMBs that are not connected to VoIP services. Taking a closer look at those already using VoIP in the enterprise or receiving such a service from their service providers, we see several common characteristics:

  • Not all branches use the same PBX. This is due to acquisitions or changes along the life of the network that were not implemented across the board
  • A hosted service was added servicing some of the branches, requiring the connecting of the on-premise PBX and phones with the hosted service network
  • A unified communications service such as Microsoft Lync was added in addition to the existing telephony system requiring the connection of the 2 networks together
  • Survivability needs and local PSTN termination require an on-premise “box” to provide these capabilities

Each one of the points above introduces complexity and a mix of standard and proprietary (or as some vendors call it, “SIP like” or “in the spirit of SIP”). As this phenomenon is the reality of today’s business networks, a smart mediation box is required to connect between the different elements and support these requirements.

What is special about the SBC that makes it the “Swiss Army Knife” of VoIP?

An SBC is like a Swiss Army Knife as it handles many functions. It is well aware of the specific environment in which it is deployed and typically has a flexible configuration that allows adapting it to the specific deployment environment. On the other hand, SBCs are also known for complex configuration due to their complex functionality. As such, a configuration wizard that contains various vendor product profiles for automatic and easy configuration of the SBC for specific deployment scenarios comes in handy for simplifying SBC configuration.  

A typical SBC would have the following functions:

Mitigation & connectivity – connect between different PBXs and different hosted services, connectivity with different SIP trunk providers.

Security – detect security threats such as denial of service, call theft and eavesdropping and protect the network from them. The SBC may also perform encryption/decryption functions to force a policy requiring all outbound traffic to be encrypted.

Quality of Service – the SBC monitors call quality, reports on issues and may enhance quality through media manipulation

Routing & policy enforcement– making sure calls routed based on the enterprise policy-based on user identity & privileges, call termination cost, quality requirements and network conditions

Regulatory compliance – route calls to recording services

The list of functions above is a general and non-exhaustive list. Naturally, there are different functionalities required depending on the type of the SBC, be it an access SBC or an enterprise SBC.

In conclusion, if in the past there was a debate about the need for an SBC, today SBCs are found in most deployments, on-premise as well as in hosted services, providing functionalities such as security and resiliency. Moreover, the SBC is included in many of the architectures defined in the standards.

Image credit: Flickr user Hiking Artist

 

Moving WebRTC Into Your Network Through the Front Door

Moving WebRTC Into Your Network Through the Front Door

As part of my work with WebRTC, I get a chance to speak to different types of companies about their WebRTC plans. When speaking with companies that have existing VoIP products and services, the conversation usually moves to how WebRTC should be added to their offering, what the additional service benefits are and how to architect the solution. The typical requirement is to leave the existing deployment untouched and bridge WebRTC into the existing network through some sort of a GW. Where should the logical function of the GW be located and what should the network architecture look like are usually the questions debated. To answer them, I decided to write this post.Moving WebRTC Into Your Network Through the Front Door

Image credit: Muhammad Mahdi Karim

To demonstrate the consideration points and options, I will use an example of a contact center. For the sake of this example, let’s take a contact center that has both PSTN lines as well as SIP Trunks from a service provider. All traffic inside the contact center is via SIP where some of the agents are working on premise and others are home agents who are “called in” for handling contact center peak traffic.

 

Architecture Options when Adding WebRTC

In my discussions with customers and partners who are looking to add WebRTC into their existing networks, the architecture alternatives considered were:

  • A dedicated GW
  • Adding a WebRTC interface to their current core server
  • Adding WebRTC through an SBC

Before and After WebRTC

BeforePre WebRTC Contact Center Connectivity

  • Traffic comes from a service provider over SIP trunks or PSTN
  • All traffic in the contact center is SIP
  • Home agents are connected over IP-SIP but this is done in a secured and controlled manner
  • The contact center core server is placed inside the contact center network. Security is handled by other elements so it is protected from denial of service attacks, call fraud and other security vulnerabilities
  • Calls are using G.729 or G.711. Transcoding, if required, is handled in the contact center network

 

After

Adding WebRTC into the game creates new requirements and a new type of traffic source. With WebRTC, users browsing the website of the company serviced by the contact center, can call in directly from the browser. Their traffic runs over the Internet directly to the contact center.

WebRTC includes 2 voice codecs: G.711 and Opus. These are the codecs that come within the browser. If the intention is to eliminate the need for download, calls must be initiated using one of these 2 codecs.

Since G.711 is not built for running over the open Internet as it doesn’t include resiliency, it is beneficial to initiate the calls with Opus. The optimal approach would be to run Opus end-to-end from the browser to the agent but in cases where this is not possible, it is best to keep Opus on the open Internet leg and transcode when getting into the contact center network.Alternatives for adding WebRTC to the Contact Center

  • The contact center is required to have a “leg” in the public Internet domain
  • Quality of service is not managed. Even though in many cases the quality is good, supporting SLA requires the capacity to manage and monitor quality of experience (QoE)
  • Supporting Opus requires either adding a new intensive computing transcoding function or adding Opus to the agent’s client

 

Alternatives Comparison for adding WebRTC to Contact CenterThe comparison above doesn’t relate to any vendor specific product but rather looks at common functionalities of such products. Given this, the following conclusion should be viewed in context of the actual functionality supported by the specific products considered.

The comparison shows that in the case of the contact center example in this post, adding WebRTC to the existing internal contact center server will yield high risk and therefore, it is not a recommended alternative.

The selection between a pure GW and an SBC would depend on priority focus. If security and QoS are of high priority, the comparison leans towards the SBC alternative.

One Voice Operations Center

The VoIP Network Management Jigsaw Puzzle

Have you ever felt that your VoIP network management system is like a jigsaw puzzle requiring you to jump from one application to the other in order to complete a full cycle of handing an issue? Well, you are not alone. Meet Alice. Alice works in the IT department of a mid-size company with 3 offices in the US, 2 in Europe and 2 in APAC. This is what happened to her last week.

8:45am, Los Angeles

Alice gets a notification on her browser-based alarm system that there is a high call drop rate in the Boston branch office. She turns to the voice quality monitoring system to zoom-in on the problem.

She waits for the monitoring system to start, it’s a different GUI so it takes her a minute to find the information on that specific branch.

Since it looks like a problem that happened repeatedly over the last 2 hours, she runs a report to get the details of all calls dropped.

She flips back for just a minute to the alarm system to make sure these are really the calls for which the problem was reported. Alice then realizes that the problem has to do with one specific SIP Trunk that is dropping calls.

She must act fast. The Boston site executive was in touch with her from his mobile several times already. He and his team are about to go into a conference call with a customer and he is worried the call will fail.

Calling the service provider support line doesn’t look like something that will solve the problem for the call about to begin at the top of the hour. It is 8:53am and there is no time for support IVR and a call queue.

Alice decides to work around the problem and bypass this SIP trunk by configuring the branch SBC to route the calls through the Chicago branch over an MPLS link. She is still on the monitoring system so Alice now needs to switch to enter system with a different GUI, for the SBC configuration system.

OK. So I made up the story and invented my character Alice. But scenarios such as this one do play out every day for IT managers.

The multitude of independent management and configuration tools, each dealing with a specific task, is a major drawback in VoIP network management. You may think that this jigsaw puzzle is inevitable as each system comes from a different vendor or simply because each product has its related system even if they all come from the same vendor. But it doesn’t have to be that way.

But Gentleman, We Can Rebuild It

One Voice Operations CenterWhat if there was an all in one unified VoIP management suite? What if call quality monitoring, alerts and management of your network servers were all managed from one system? Well…that is exactly what AudioCodes One Voice Operations Center is all about.

The AudioCodes One Voice Operations Center is a suite of management tools providing full coverage of the entire set of actions required to manage a voice network in a Unified Communication environment.

It uniformly manages, monitors and operates the entire AudioCodes One Voice portfolio, including SBCs and Media GatewaysMicrosoft SBAs and IP Phones.

For example, in case of an enterprise using a Lync server, the One Voice Operation Center provides a complete view of the network voice quality, including Lync client to Lync client calls and Lync to PSTN calls. All in real-time. And if you need to fix a configuration, there is no need to go far. The same suite provides a provisioning interface to manage all your SBAs, SBCs and gateways.

Want to learn more? Come visit our booth #625 at the ‘Lync Conference’ to watch a live demo of our ‘One Voice Operations Center’.

Secured Approach to Cloud Telephony Services

A Secured Approach to Cloud Telephony Services

Secured Approach to Cloud Telephony Services

Image credit: Flickr user opensourceway

One of the common dilemmas to most “mission critical” cloud service providers is whether an on-premise border gateway or tool should be part of their architecture for connecting on-premise software and HW appliances to their cloud services.

The purposes of such a border gateway or tool are various and depend on the cloud services provided. For example, a familiar tool is the AWS Storage Gateway. This gateway connects on-premise appliances to the Amazon Cloud storage services. Other cloud services such as big data analytics and network performance monitoring architecture may include on-premise tools for remote sniffing, data gathering, filtering, transforming, preliminary analysis and mass data transport.

When thinking of using a cloud service for enterprise telephony, a common decision point is whether to connect the enterprise IP Phones directly to the telephony service provider or to deploy an on-premise cloud appliance.

Actually, an enterprise cloud-based VoIP services architecture, dictates the need for an on-premise Session Border Controller for basic operation solving connectivity, (i.e. NAT traversal), security, resilience and quality issues.

Connecting the enterprise to the service provider cloud through VPN

Trying to reduce costs, VoIP service providers often bypass connectivity and security issues by connecting the Enterprise to the cloud using VPN over IPsec or MPLS-VPN service with or without standard End-to-End Service Level Agreements and performance reporting.

Both VPN-IPsec and VPN-MLPS connections simulate a L2/L3 LAN with the service provider. This architecture obviates the need for NAT traversal and on-premise VoIP security, as VoIP clients and IP phones share the same IP subnet with the service provider SBC.

Enterprise-Cloud-Over-VPN

VPN connection between the enterprise and the service provider

Adding Multitenancy

This approach may be satisfying for private or dedicated cloud architectures, although it doesn’t provide a solution for resiliency and voice quality monitoring. However, for cloud-based VoIP service providers who provide service to multiple enterprises, this approach is problematic.

Multi-tenant-SBC

Multiple tenants connected to the service provider through VPN

Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server or HW system, serving multiple client-organizations. Although multitenancy can be achieved by running multiple instances of the application, in most cases multi-tenancy is designed by virtually partitioning an SBC data and configuration. Each tenant works with a segregated non-bleeding virtual application instance.

Multi-tenant cloud-based VoIP services share a single application server instance (i.e. IP PBX, application servers) and network entities instance (i.e. access SBC, peering SBC) between several tenants.

Seemingly, multi-tenant shouldn’t present any security or other issue, but in reality, this tenant segregation is almost impossible since, after all, tenants may share network interfaces (same IP and port 5060), and a SIP trunk or MGW in the northbound, so the segregation is not complete. An attack on one of the tenants or a misconfiguration of one of the shared resources, compromises all of the tenants’ security. In such a case,  as the tenants are sharing the same L2/L3 with the service provider and relying on the service provider IDS (intrusion detection server) and IPS (intrusion prevention server), a simple intrusion can be destructive.

Cloud-Appliance

 An SBC as demarcation point between the enterprise and the service provider

Isolating the enterprise from other tenants’ security threats

Organizations that can’t afford compromising their security and can’t trust 3rd party security services, should deploy an enterprise SBC as a demarcation point.

An Enterprise SBC provides:

  • Support for back-to-back user agent (B2BUA) functionality
  • Security and privacy (personal information is not forwarded to the cloud)
  • Emergency calls and regulatory
  • Resiliency
  • Remote Agent termination
  • Registration throttling
  • Voice Quality Monitoring
  • Call Admission Control and Rate Limiting.
  • Registrations overload and avalanche protection
  • On-premise recording, the SBC forks the calls

Finally, cloud-based VoIP services can be connected to an Enterprise via VPN-IPsec or VPN-MLPS without the need for an Enterprise SBC. However in choosing this path, the enterprise loses much of the above mentioned functionality related to the SBC and puts the enterprise in a security risk as well.

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.