Use Real ROI Numbers to Pay for Your New Phone System

Use Real ROI Numbers to Pay for Your New Phone System

Use Real ROI Numbers to Pay for Your New Phone System

cisco 7965 phone

Money is tight these days, and only the most essential projects are getting funded. In the data networking realm that means all projects have to show tangible immediate benefits, and save money to boot.

In the Return On Investment discussion, these can often times be split out into hard dollar and soft dollar cost savings. Hard dollar costs are what the organization pays out in cash every month, quarter, and year. For example, PBX lease payments, voice trunk line charges, or call center staffing level, are all examples of hard dollar costs to which savings can be applied.

Soft dollar costs can be more significant, but they are harder to quantify. If it is possible to enable people to work faster, have access to data more quickly, or provide a higher level of customer service, it is clearly a benefit to the organization. Over time those improvements can be responsible for a higher net profit, but since they don’t involve the writing of checks from finance every month they are classified as soft cost from a ROI standpoint.

Let me give an example of an ROI calculation. We were working with an Atlanta company that had offices all over the southeast and they had a big problem. Their PBX leases were coming due. They were disenchanted with the costs and limited performance of their existing system and were looking for something new.

As a side note, one of the common ways that traditional PBX vendors sell is a system is to focus only on the monthly number, in a similar way that some car dealers do. The vendor lists out an entire system, prices it using a FMV lease, includes service and maintenance for the duration of the lease, and only gives one price — the monthly cost. The problem is, with a Fair Market Value lease, the residual value of the PBX is unknown! At the end of the lease, the customer finds out they have been paying every month, and have no assets at all to show for it!

At any rate, this organization was looking at either an Avaya system or a Cisco system to upgrade to. Since we focus on Cisco, he had to look somewhere else for Avaya. After completing the system design, pricing it out, and running it through financing (with a $1 buyout of the system at the end of the lease!), we had a monthly price.

Not surprisingly, the price was too high. That is one of the mistakes commonly made when specifying a Unified Communications system. Because not only does the phone system have to be replaced, many time the LAN switches and WAN routers have to be upgraded as well. This can make for an expensive project when one looks at just forking over the cash. Couple the price with the disruption of business processes that can happen with a voice system changeover makes the decision maker just want to not think about it.

A more successful way to approach the discussion is to quantify the hard dollar cost savings of the project. It is easy for vendors to wave their hands and say, “Our customer across town, with a business just like yours, is saving $20,000 per month by using our system!” It is more difficult to be specific about the exact hard dollar cost savings.

When looking for ROI, a simple tactic is to look for where the large monthly expenses are. If these expenses can be reduced or eliminated, then the project has a much higher likelihood of being funded. So we set about doing just that. Looking at the spreadsheet excerpt below, the existing costs are quantified on the left, and the proposed costs quantified on the right.

The monthly finance payment was generated from an equipment and installation price of $260k, an annual manufacturer maintenance price of $40k, and a 5% annual interest rate. Financing is for 5 years with $1 buyout. It includes all LAN, WAN, UC voice, and installation pricing , with manufacturer maintenance for all five years.

The pricing requires further explanation. For the 17 sites, they were connected by Virtual Private Network, or VPN. When all the phones in the organization are part of one big UC installation, VPN/DSL connected sites only work for very small offices with 2–4 users. All the rest have to be connected with a Private Network, the most common these days being MPLS. Unfortunately, the new Internet and MPLS WAN for this customer ended up costing more than the existing Internet VPN connections. This is not good for ROI.

There are multiple benefits to the MPLS WAN, though. One of the biggest ones is that it can replace almost all of the voice T1’s and analog trunk lines at every site with a SIP trunk. All the existing local phone numbers are ported over to the SIP trunk, and all inbound and outbound calls go over this data link. This is where the real cost savings come into play.

As a side note, just like MPLS (MultiProtocol Label Switching), knowing what SIP (Session Initiation Protocal) stands for doesn’t really help at all.

So, the customer could extend the lease on their PBX’s, and continue to pay $26k per month, or they could get an entire new data network and a new phone system, fully installed, and pay $20k per month. That’s pretty much a no-brainer from a cost savings standpoint.

But it gets even better! The finance guy is now ready to listen because we have demonstrated how the new project will save real money on a monthly basis. Remember the soft dollar cost ROI discussion above? This now comes into play.

With a new phone system, there are multiple benefits that can potentially improve productivity:

  1. Inbound Automatic Call Distribution (ACD) for better customer service.
  2. Four digit dialing from any phone at any site to any other site. No more calling the main number for the other site, chatting with the person who happened to pick up the phone, then a few minutes later talking to whoever you intended to call. Just pick up the phone and call them!
  3. Presence and chat integration into the workstation. See when anyone else is on the phone or not, and run an internal, secure chat server that lets you have a conversation with a co-worker while they are one the phone.
  4. Centralized management of all the phone systems from a web browser. That means no more contracts with local phone companies in every town. A new employee can have a phone ready and working for them within hours of starting.

These are just some of the soft dollar cost ROI benefits from a Unified Communications system. There are others that I will list out in detail in another post.

With the combination of monthly cost savings, soft dollar cost benefits, and the upgrade of the entire network, the decision was made to proceed with the project. It turned out well, and the benefits of the increased productivity and cost savings were actually realized.

What I have found through many processes like these is the necessity of finding out what the organization is spending too much money on. The line in the spreadsheet for conferencing is there because some organizations spend a large amount of money on conference calling services every month. In many cases those conference calls can be managed internally for a lower cost.

Same thing with Project Office voice. Some organizations set up 2–4 month project offices at remote sites. It is expensive to arrange and deliver voice and data service to these sites; so the alternative of dropping in a voice gateway, switch, and phones, and having the system run off the main site system is very appealing.

The ROI of Unified Communications systems is very real. What is needed in many cases to make the project move forward is the actual information on what the organization currently spends, and the ability to show real numbers on both hard and soft dollar cost savings.

Author: Rolf Versluis
Adcap Network Systems — Atlanta and Miami
Great Local Engineers Creating Systems that Work!
Posted at Adcap Tech Tips

Choose the right IP phones and POE switches

Choose the right IP phones and POE switches

Choose the right IP phones and POE switches

Cisco 3750-X switches

Last year we learned a lesson about POE switches the hard way. Cisco had some nice new gigabit phones start shipping, and had been shipping gigabit POE switches to power them. One of our customers wanted gigabit ethernet to their desktop, so we specified the gig phones with the gig switches. Since all the switches were going to be in one closet, we recommended four 48 port POE switches, along with 120 POE phones. Everything was going great, until we started putting the phones out on the desktop.

(As a side note, even though the voice traffic over Ethernet is about 87kbps, it costs less to run a single drop to the desk that can power the phone and connect the workstation, since it would take twice as many ports in the closet and Cat5E drops to run 10/100 to the phone and gigabit to the desktop.)

Most of the phones booted right up, but some appeared to be dead. There are usually very few phones that arrive broken, so we tried plugging them directly into the switch. Some of them worked, some of them didn’t. Puzzled, the tech ssh’d into the switch to see what was being logged.

The switches were the 48 port Catalyst 3750 POE switches, and the handsets were the CP-7941G-GE’s, which have now been replaced by the CP-7945G phones. The CP-7941G-GE’s are gigabit speed versions of the CP-7941G phones; otherwise they are the exact equivalent. See if you can spot anything fishy about the combo from the datasheets. No? I didn’t either.

Here’s a hint from the phone datasheet:

Power Requirements

The phone supports IEEE 802.3af PoE (the phone is a Class 3 device); 48 VDC is required; it can be supplied locally at the desktop using an AC-to-DC power supply (part number CP-PWR-CUBE-3=). Use of the power supply also requires ordering one of the AC country cords listed in Table 6.

From the switch datasheet:

Measured 100% Throughput Power Consumption

(with maximum possible PoE loads)
Cisco Catalyst 3750 Series
Switch Power
PoE Power
Total Output BTU




311 BTU/hour




404 BTU/hour




414 BTU/ hour




581 BTU/hour

And finally from a technical note buried on this page:
Table 1 IEEE 802.3af PSE and Powered-Device Power Classifications



Minimum Power Levels Output at the PSE

Maximum Power Levels at the Powered Device


0.44 to 12.95W


0.44 to 3.84W


3.84 to 6.49W


6.49 to 12.95W


Reserved for future use
Treat as Class 0
Reserved for future use: A Class 4 signature cannot be provided by a compliant powered device

The problem occurred whenever the 29th phone was plugged into the switch, and the message was that the switch had hit the limit of its power budget! Now, if I buy a 48 port POE switch, I expect to have 48 ports that I can use for phones. I think most people would. This was an unexpected and unwelcome surprise.

However, the message on the switch was correct. Let’s do the math.

With the CP-7941G phone that we had been using for the last 2 years, 48 powered phones per switch was the case. It is an 802.3af Class 2 device, and requires 7 Watts max at the port. 7 Watts x 48 port = 336 Watts, which is well within the power budget of 370 Watts on almost every Cisco stackable switch, whether they have 24 or 48 ports.

The change in speed from 10/100 on the CP-7941 phone to 10/100/1000 on the CP-7941G-GE phone somehow caused Cisco to reclassify the new phone as a 802.3af Class 3 device. That requires maximum power of 15.4 Watts. If you divide the switch power budget of 370 Watts by 15.4 Watts, the result is exactly 24.

The reason 28 phones are supported is found in this FAQ:

Q. A Catalyst 3560 switch with 48 ports supports 370W. Because C7941G is a Class 3 device, it requires up to 15.4W. Can this be reduced to 7W so that the switch can power all 48 phones?

A. If Cisco Discovery Protocol (CDP) is enabled, there is no need to reduce the power requirement to 7W. The phone is classified as a Class 3 device when it first powers up, but after it powers up, CDP sets the desired power level on the 3560 to 7W. This allows the switch to support 48 ports of phones.

Note: If you use C7941G-GE, it is not possible to power all 48 phones. C7941G-GE usually draws 12.9W. The total power available is 370W, and for 48 ports, this evenly divides up to ~7.71W per port. In this case, the 3560 switch can only support 28 phones that draw 12.9W each.

So, whether the switch has 24 or 48 ports, the maximum quantity of gigabit speed Cisco phones that can be plugged into it is dependent on how much power each phone draws, which for gigabit phones means a maximum of 28. That rule holds true for every 2960, 2975, 3560, and 3750 series switch that Cisco ships. The only switches that can power 48 gigabit speed phones in a 48 port switch or switch blade are the 3750E, 4500, and 6500 series switches, which I will discuss some other time.

Another handy FAQ answer from the same source:

Q. What are the power requirements for the various models of the IP phone models?

CP-7902G (6.3W)

CP-7905G (6.3W)

CP-7910-SW (6.3W)

CP-7910G (6.3W)

CP-7912G (6.3W)

CP-7940G (6.3W)

CP-7960G (6.3W)

CP-7906G (5W) (Class 2)

CP-7911G (5W) (Class 2)

CP-7941G (6.3W) (Class 2)

CP-7941G-GE (12.9W) (Class 3)

CP-7961G (6.3W) (Class 2)

CP-7961G-GE (12.9W) (Class 3)

CP-7970G (10.25W) (Class 3)

CP-7971-G-GE (15.4W) (Class 3)

CP-7985G (12.55W) (Class 0, Not full brightness)

IEEE 802.3af Device — Class 0 (15.4W)

IEEE 802.3af Device — Class 1 (4W)

IEEE 802.3af Device — Class 2 (7W)

IEEE 802.3af Device — Class 3 (15.4W)

So, what did we do? What could we do? We admitted our mistake to the customer, worked with our great Cisco account manager and our wonderful distributor, and got the four 48 port gig switches swapped out for eight 24 port gig switches at the same exact price. We got the exchange turned around in a day, worked late and extra hard, and got the system rolled out on time.

Lesson learned, again.

Should we have known this before we specified the system? Maybe — that’s a tough question. The information is definitely in the datasheets, but it could certainly be clearer. I just keep telling myself that the accumulation of experience from mistakes like this one turns into wisdom at some point.

Author: Rolf Versluis
Adcap Network Systems — Atlanta and Miami
Great Local Engineers Creating Systems that Work!
Posted at Adcap Tech Tips

SIP trunking is a big deal — for saving Money

SIP trunking is a big deal — for saving Money

SIP trunking is a big deal — for saving Money

Two and a half years ago Cisco came out with Call Manager version 5. There were a few notable changes in this release. Besides running on linux, it was the first version that supported both SIP phones and SIP trunks. As fortune would have it, one of our customers at the time had more prescience than I, and had researched the cost savings capabilities of using a SIP trunk for PRI replacement. Since I have never shied away from deploying the latest Cisco voice technology, we agreed to put the system in place.

The cost savings of the SIP trunk is what funded a majority of the deployment.

Since the customer had a main site in Atlanta with 3 PRI’s, servers in a local colocation facility, and 9 remote sites, each with its own PRI, there were 12 PRI’s that could be eliminated. By putting in an MPLS WAN at the same time, ten internet T1’s could be turned down as well, which was a wash as far as pricing went. The SIP trunk plan included all long-distance as well, which was a further cost savings. An important point is that the local numbers on each of the 12 PRI’s were ported over to the SIP trunk, so no phone numbers had to be changed.

The cost savings of 12 PRI’s is about 12 x $600/month, or $7200/month. The SIP trunk cost about $3000/month at the time, so that left $4200/month for financing equipment and installation. Furthermore, the customer received the other standard benefits of a Unified Communications system, including a single point of system management, 4 digit dialing between all sites, and managing the voice system like any other application running on a server.

Things were rolling along great on the deployment. The SIP trunk was working for inbound and outbound voice calls, the SIP loads on the handsets were doing well, all the Quality of Service was set up properly so voice quality was good. We were going through the SIP trunk signoff checklist when we got to the line about DTMF tones. Although it seems minor not to be able to use the keypad during a call, this turned out to be the starting point of a very educational process for me.

It turns out that although SIP is a standard, at that time not every piece of network gear implemented all parts of the standard. The SIP trunk provider sent and received DTMF tones inband. The Cisco call manager and voice gateway sent and received DTMF tones as inband INFO, or what is known as RFC 2833. The provider and Cisco were both compliant with the SIP specification, but each with different parts of it!

Nowadays all SIP trunk providers are RFC 2833 compliant, but it was a major issue then. The only way to solve it and get the system into production was to turn up two Asterisk servers, and use them to perform the conversion, but that is a whole nother story.

The next issue I ran into was faxing. Now, faxing over VoIP networks has always been something that has to be dealt with in a methodical fashion, and we got the majority of the faxing worked out properly. The issue came with turning up the Fax over IP server. We use the market leading Xmedius product, and it is great because it takes a direct T.38 feed, and can be set up with either H.323 or SIP. Usually we take the PRI into the voice gateway, convert it to T.38, and send it to the fax server, and everything works great. Unfortunately the SIP trunk provider did not send faxes as T.38.

Just like the DTMF tones were sent as noise in the RTP stream, the faxes were sent as noise in the RTP stream as well. After a bit of thought, I ended up terminating the fax calls on a Cisco IPIP gateway (now known as CUBE), sending them out a PRI port as inband fax, looping that back into the same router, and converting them from PRI to T.38 fax. After that the faxing worked fairly well.

All the calls were coming in from the SIP trunk provider as G.711. For the remote sites we transcoded those to G.729 to save bandwidth. That was planned for and it worked well. Later on the customer bought more bandwidth and had all the calls running as G.711 since they liked that level of voice quality better.

After a week or two of the system running in production, we started to get some complaints about calls to outside IVR systems. Instead of calling in and receiving a menu, the call would just ring and ring. It was puzzling and took quite a bit of troubleshooting through SIP logs to determine the issue, and the solution.

Basically, these IVR’s required the call to be connected on our side before they would answer the call. My understanding is still somewhat incomplete, but the answer was that SIP early media was required on all outgoing calls.

SIP early media was generated at the Cisco Call Manager by checking the MTP required check box of the SIP trunk, which at that time defined the codec as G.711 and connected the call. That required provisioning of multiple MTP resources. The Call Manager could only have 24 MTP resources, so I had to define software MTP’s on the voice gateways. In this deployment defining two voice gateways at the colocation facility with MTP’s worked out just fine. It turns out that every SIP deployment has the same requirements for early media, so now I just cut to the chase and define the MTP’s properly up front.

After working through the DTMF, T.38, codec, and early media issues with MTP’s, all that remained was the basics of any good voice deployment, which is a high level of attention to detail, proper end-user training, and immediate followup with any perceived end-user issue. End-users don’t care about the technical issues, of course. They just want it to work.

In subsequent deployments at other customers, where the SIP trunk is being provided over the MPLS WAN, the precise definition of Call Manager Media Resource Groups and Lists, with the careful ordering of MTP’s on remote voice gateways, is absolutely essential to good voice quality and proper bandwidth utilization. MTP’s are tricky to do correctly, but they are an essential part of a multisite SIP deployment and have to be handled properly. MTP issues often appear to be QoS issues, which makes them even more difficult to solve.

Cisco is now on Call Manager version 7. We are finishing up a 20 site SIP deployment at a local customer, and everything is humming along fine. They are saving lots of money on phone bills, have a shiny new phone system and network in place, and are experiencing a high level of both reliability and voice quality.

SIP trunking is definitely a big deal, and it can certainly save an organization a lot of money. There are definitely many details that need to be addressed in any multi-site SIP deployment to ensure success, and anyone that says otherwise does not have the depth of experience to conduct one properly.


Posted at: Adcap Network Systems Blog

Posted at Adcap Tech Tips

Author: Rolf Versluis

Twitter: @adcapnet
LinkedIn: Rolf Versluis LinkedIn
Facebook: Adcap Network Systems Facebook Page
Adcap Network Systems — Atlanta and Miami
Great Local Engineers Creating Systems that Work!