I designed this website with the impossible mission to appeal to the novice and the non technical alike. So articles like this propose a challenge that I hope through the blog, I can overcome.

There are multiple phases to a VOIP project. There are many similar characteristics regardless of enterprise or carrier, small or large that need to be defined before anyone starts with the initial design. Here are the different components of a typical VOIP environment. The terms vary but the philosophy is still the same.

1. OSS/BSS
2. Voice components
3. Security components
4. Network Infrastructure
5. Extra Services

OSS/BSS

OSS = Operational Support System

This term is mostly understood in Carrier designs, but it is no different than in the enterprise. It defines the systems that are responsible for provisioning, monitoring, and reporting on the VOIP infrastructure. Security usually is taken very seriously when designing the OSS environment. Components of the OSS are:

Subscriber provisioning

In the enterprise you don’t call your end users subscribers; however that is what they are. Every end user of your VOIP environment is your customer and therefore subscribe to particular services. If you are running video conferencing for example, then signaling will definitely need to take place in the VOIP environment and need provisioning as well.

In most solutions, provisioning is performed on the server using a http connection, or https for security.

Voicemail Subsystem

There are other provisioning systems that need to be designed very carefully in regards to security and network infrastructure layout. One of these systems, which is increasingly popular in countries outside of the US are customer-provisioning voicemail subsystems.

These are subsystems that allow a subscriber to set up their own voicemail preferences, and provide a subscriber with 100 percent control over if they want to use SMS (text messaging) to read their voicemail. Or even decide if they want voicemail at all.

There are also solutions on the subscriber provisioning that allow subscribers to provision their own services and not deal with the hassle of dealing with a customer service representative.

Network Health Management

I put a fancy title for this one, but it is plain old network management. What makes it different is the complexity of the solution.

Network management is management by SYSLOG and SNMP to monitor the events in your network. Even though this may sound simple, it isn’t. Due to the wide array of VOIP equipment manufacturers in the market today, setting up network health management is a very challenging ordeal.

However, for consultants and professional services organizations, this is the money shot of any project. It takes capital to have a well monitored environment.

Miscellaneous – A little Professor-ism

VOIP is just as understood in the Carrier level as it is in the Enterprise. Carriers are just as likely as enterprises to take a solution from a known equipment provider as is, at a very hug price. They substitute on staff knowledge with a support contract and from day one of service they still do not know how to support their own platform.

Most carrier solutions are installed on a Solaris server. This is due to the reliability and stability of the product. This prevents them from having to spend a lot of capital on a hardware engineering department in India.

This provides a benefit to the purchaser. Most carriers have to provision more than one subsystem when provisioning their subscribers, why not create an API to one platform from each platform that you need to provision? It will save you in overhead, improve performance, and customize your environment to better suit the needs of your organization.

This had a carrier environment focus. In the enterprise, it isn’t that easy. To explain, I have to use metaphors so you can envision. Think of buying a car, there are two kinds of people who purchase vehicles, ones that know vehicles inside and out, and the average person who just purchases whatever may sound good at the time.

When the expert looks at a vehicle he sees right away what he would have to change in order for the vehicle to provide what “he” wants. When the average person looks at a vehicle he just wants to know how much he would have to give in order for the vehicle to work for him. Meaning to have a sunroof and a cd changer can he deal with being uncomfortable, or would he like to be comfortable and live without the sunroof or cd changer and possibly pay someone down the road to customize.

The expert looks at the vehicle with the features that already best fit him and will already figure what changes need to be done. He purchases the most cost effecting solution with the bare minimum and plans his customization up front. In the end, he has a solution that best fits his need, while the average person has a solution that he can call serviceable.

The two approaches are similar to the approaches to VOIP infrastructure and is very common. However, once VOIP knowledge and expertise grows it would be easier for companies to take a leap to better prepare and customize their infrastructure.

VOICE Components

There is too much one can say on VOIP components and it would be smart to leave for another discussion. We can go over the basics. Naming and terminology differs from vendor to vendor. And now with the carrier community adopting the IMS standard the naming gets more confusing. The modules stay fundamental however.

Signaling Gateway: This is more or less a component for Carrier networks. It handles the MGCP and SS7 signaling.

Call Management Server: other names Call manager, signaling server. Depending on solution this server is responsible for subscriber management and sip signaling. In some solutions it is modulated further or all in one platform. This would be where you provision the subscriber, set the dial plan or Digit Analysis, and this is also where you will answer sip signaling requests.

Security components

SBC- Sip Border controller: This unit is a proxy component for sip. It handles stateful inspection of sip signaling. It also handles topology hiding so that anyone in the public network does not know what hides behind the “sip firewall”.

About 5 years ago, I really thought this functionality would make it into the signaling server. Due to it makes more sense to do topology hiding and stateful inspection on the platform itself. There were only 2 real leaders in the SBC market, Acme and Kagoor. In the last 5 years the market has grown to 22 makers of the SBC and very few vendors incorporate it within their softswitch solution.

BTW, Kagoor was acquired by Juniper in 2004 and has since lost most of it’s market.

Solution for web based IDS and IPS. This topic should be a whole article by itself. There are many security solutions made for provisioning of services for Voip. In fact, the more features you provide for your customer base the more security you will need.

Let’s take for example a web based voicemail system. A system that lets you change your parameters, buy more storage and so forth. If you have any system administration experience you already see the complexity of finding a solution.

Network Infrastructure:

Typical design rules apply when designing a network infrastructure for VOIP. VOIP is high availability so close attention must be paid to redundancy. Most redundancy design is provided with sub-second failover. This is easier said than done, but it is very possible. The more components you have to play with the harder it is to provide.

When designing VOIP end to end is of bigger importance, you must be able to account for all of your delay in a particular network environment. This mostly applies to enterprise environments. End to end delay must not exceed 50 ms.

In the enterprise environment, I am never surprised when you ask an engineer what codec’s they are using and they have no idea. However, they can tell you that they have QOS. It is unbelievable. Two rules apply to a VOIP infrastructure:

1. Know your VOIP traffic: meaning know your codec
2. Know your end to end delay

Number one applies to the principal of design. You must know what is running through your network in order to design appropriately. For example, if you have 20 phone endpoints requested then you need to know what codec you are using in order to calculate you requirements. If you are using G.729 for example then you nominal requirements are 32kbs per user. G.711 then you requires 88kbs per user. If you are looking for a rule of thumb, I always go 80kbs per user to figure in comfortable signaling and Voice requirements.

You also need to know if you do not know what you are doing, leave QOS alone!! QOS is used to break stuff. You may laugh but think of it, any Quality of Service that you implement always degrades something else. So when using Voice you must know that every network device introduces serialization delay. Also know that ever interface you a forwarded out of has a queue. Queuing is Voice’s worst friend so eliminated it. That is all of the quality service you should need. There are always exceptions so please know your environment.

Extra Services

There are many extra’s when it comes to voice. Majority of the softswitches try to include scaled down versions of these extras to entice more customers, but those who have worked in the environment know that it pays to have the full version on these solutions.

Advanced call routing features:

This includes the solutions that provide advanced call routing as number routing per hour or per day. For example, let’s say that you are a General Manager for “always broken toy inc”. Well you have to travel around to different locations and you will need an office number to follow you. From the hours of 8am to 10am you are in commute so calls will go to your receptionist. From 10am to 2pm you are always in your downtown office so calls will be forwarded to your office there, and so forth.

Many PBX’s require additional features to make this happen, however in the world of softswitches this is almost always an additional service.

Short Messages Service = SMS = text messaging

If you want this done right, this is a solution in itself. The SMSC is the most critical component and it is the component that routes your SMS traffic. This is very important when you are in the cell phone market and want to provide text to speech services. However, Sip gives that functionality as well and there are many phones out there right now that support SMS.

Summary

I have only provided a few examples and this was a very brief look inside of VOIP components. I could go on and on and as far as experience goes, I can tell you that VOIP evolves quickly. It is difficult to slow down in the VOIP market because of the development of more products and advance technology.