Comments on: Writing an RFP for an Open Source IP PBX – Part2

By: up to date

up to date — Thu, 05 Jan 2012 07:30:59 +0000

I really want to believe that its safe to listen to you. I just read the preliminary report about the inquiry into why people were infected with hepatitis C and HIV from contaminated blood and blood products. Hundreds of people in Scotland, including haemophilia sufferers and other patients, were given contaminated blood in the over a period of about 20 years. Which is completely beyond belief. I found this site on home remedies for piles and everything looks to be true.

By: slacker

slacker — Fri, 29 Apr 2011 19:44:46 +0000

Awesome article , I’m going to spend more time reading about this topic

By: IUD Side Effects

IUD Side Effects — Wed, 01 Dec 2010 20:04:27 +0000

gaming computers should have multiple cpu cores and a lot of memory to support those heavy graphics ~~’

By: Disease Treatments

Disease Treatments — Tue, 19 Oct 2010 07:48:57 +0000

Kaspersky will definitely get two thumbs up from me when it comes to killing all those pesky viruses and spywares,”.

By: Isabel Russell

Isabel Russell — Mon, 04 Oct 2010 15:31:53 +0000

Kaspersky and Avast are both great antiviruses and anti-malware,`:

By: Bruce

Bruce — Wed, 19 May 2010 16:19:44 +0000

Nice article. I need to read part one. I would like to add one thing that could/should be in part one. Clearly state your objective as to why you are issuing an RFP in the first place. I believe the majority of ALL companies should hire a consultant in this day and age. Especially medium and small because they don’t have the resources. It is important to know the “gotchas” but even more important to understand how implementing some of the applications/features/capabilities can really impact a customer bottom line.

By: Rich

Rich — Tue, 13 Oct 2009 03:39:14 +0000

By: Aaron Rosenthal

Aaron Rosenthal — Thu, 01 Oct 2009 22:17:40 +0000

Justin, Thanks for the additional comments… you add some very good points. Glad you liked the article!

By: Justin Zimmer

Justin Zimmer — Thu, 01 Oct 2009 18:22:35 +0000

Aaron -

Great article, but as far as interfaces go, you’re forgetting about FreePBX. It wouldn’t require a licensed product for a vendor to offer an admin and user interface. FreePBX allows for complete configuration without messing with the command line. In addition, I would expect one of the more important items on an RFP would be the support contract. The scariest part of spending oodles of money on any system is for the vendor to tip their hats and bid adieu without any promise that they will be there to your hand while you break in the new system, and to fix it when it breaks. A CEO that’s never heard of this Asterisk thing will go with a proprietary solution that’s hundreds of thousands of dollars more if he’s more comfortable with the name and the promise of support. A system that quotes for that amount of money, has to have a suitable return on investment to recoup its cost. Meaning that the operation surrounding the system will undoubtedly suffer a tremendous financial handicap should the system go down, making a larger initial investment worthwhile, not to mention the peace of mind. When writing an RFP, you need to make sure your vendor is going to be by your side making sure the thing works for the first 90 days at least, and then accessible during operational hours for further support. Whether those hours are 9-5 or 24/7 needs to be outlined in the RFP.

In addition, any IP solution should have a measure of VoIP engineering involved in the quote. The vendor should be asked to evaluate the network and point out any weaknesses that may contribute to poor voice quality. It IS generally recommended to seperate voice and data networks, but not necessarily physically. Most network engineers would implement a VLAN for each network type in order to better manage QoS. It may seem overkill to do this on a LAN, but even a LAN can have problems that will affect voice quality. Vendors walk into many a medium sized business only to find a rat’s nest where the network cabinet should be. Old hubs and switches might work adequately for web browsing, or those ancient AS5400 terminals, but suddenly adding a myriad of network devices that rely on real-time data streams for their function can truly show the deficiencies in a network.

When writing an RFP, if planning on tackling a full IP solution, the RFP should require a VoIP engineering session, especially for outside communications. What other SIP components are necessary for the outlined operation other than just a PBX? Will this solution require a proxy or SBC of some type? Will you be interconnecting more than one office? Does your operation have certain security requirements that might require certain encryption or even a VPN. There are Open Source solutions for all these questions, and your vendor better have answers to all of them or else you’ll find yourself at the mercy of Cisco.

I understand you didn’t want to go too deep into call center RFPs, but since this is my area of expertise I’ll just add that a call center RFP needs to take into consideration integrations with an existing CRM, or the implementation of a new CRM that openly integrates with the OS PBX or Telephony Platform of choice. There are numerous integration opportunities with Asterisk at the desktop application level. Some come right out of the box such as SugarCRM, and others might require some development such as a proprietary solution. For a call center RFP, you need to outline the system that requires integration, and ensure that the vendor has the expertise to pull it off.

I do agree that the last thing you need is your PBX vendor fiddling around in your wiring closet, but a serious vendor will sub-contract on areas of the RFP that are outside their specialization, often using a vendor they themselves trust and have a working relationship with. One thing to consider is having two contractors butting heads over what needs to be wired and whose responsibility it is to do what. The last thing you want is one vendor sitting on their thumbs while waiting on another, leaving you to crack the whip. Keeping the blame in one place is crucial to any successful implementation. As a vendor, I love blaming the other guy when things aren’t done, but as the customer, I want to talk to one organization whose responsible for the entire project.

By: Scott Holtzman

Scott Holtzman — Thu, 01 Oct 2009 02:24:42 +0000

Aaron –

Interesting article. I wanted to challenge a statement you made:

Quote:

“SIP as your primary phone service that call can in many cases ride un-altered from the handset all the way through the carriers network and the transcoded to the work on the receiving end. By eliminating the need for the PBX server to transcode the call, you save resources and in-turn increase the call capacity of your server.”

SIP is a signaling protocol. The bearer path (audio) is transmitted over RTP. To eliminate transcoding you must match your handset CODEC with the trunk CODEC. This does not guarantee you immunity from downstream transcoding on the carriers network.

As a provider of private, dedicated SIP trunking we are constantly looking for ways to differentiate our product from Internet based Voip solutions.

Thanks for your contributions to the Voip community on Linked in