Aside from all of the many technical issues with installing the new VOIP PBX system, the biggest problem I have seen is moving from a traditional "Key System" to a "PBX" setup. With a PBX, you are completely changing the ways the customer's phone system is works (i.e., the customer's call flow is completely different with a PBX). While there are always work-arounds, most customers don't like radical change, and PBX systems have a hard time mimicking key system behavior. This causes a lot of grief with customers during (and after!) the transition. You can try to deploy shared lines to mimic key system behavior, but shared lines and VOIP don't always mix well (not all that reliable and some PBXs don't support them!). This is especially true when there are a lot of phone lines (more than 5!). So, you have to use Page/Park/Retrieve and/or Transfer functions instead. You will find that most customers are not happy with the change because it requires more "key presses" and is more difficult to remember all of the codes and/or softkey sequences. While some of this can be addressed with good training and a lot of hand-holding, ultimately, the customer will not be excited about the new phone system. Most customers simply want their old key system with the lower cost of VOIP. This is one of the reasons why SIP trunking is such a popular solution these days. They get their existing call flow with the cheaper call rates. Of course, the customer that is rapidly expanding and has requested new features is going to embrace the new PBX features and its many efficiencies... But, from my experience, most key system customers want to keep the call flow changes to a minimum, which is really hard to do when converting to a PBX. You really need to set expectations upfront, during the sales process, that they are getting a PBX and not a new key system. My two cents. EJ -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of voiceops-request at voiceops.org Sent: Wednesday, February 01, 2012 9:49 AM To: voiceops at voiceops.org Subject: VoiceOps Digest, Vol 32, Issue 2 Send VoiceOps mailing list submissions to voiceops at voiceops.org To subscribe or unsubscribe via the World Wide Web, visit https://puck.nether.net/mailman/listinfo/voiceops or, via email, send a message with subject or body 'help' to voiceops-request at voiceops.org You can reach the person managing the list at voiceops-owner at voiceops.org When replying, please edit your Subject line so it is more specific than "Re: Contents of VoiceOps digest..." Today's Topics: 1. Re: Experiences with VoIP and 100+ seat sites (Tim Bray) 2. Re: Experiences with VoIP and 100+ seat sites (Jay Hennigan) 3. Re: Experiences with VoIP and 100+ seat sites (Carlos Alvarez) 4. Rephrased Question: 100+ seat MIGRATIONS to VoIP (Darren Schreiber) 5. Re: Experiences with VoIP and 100+ seat sites (Sean Grossman) 6. Re: Experiences with VoIP and 100+ seat sites (Alex Balashov) 7. Re: Rephrased Question: 100+ seat MIGRATIONS to VoIP (Carlos Alvarez) 8. FW: Linksys PAP2T (Scott Berkman) (Jastak, Eric) ---------------------------------------------------------------------- Message: 1 Date: Wed, 01 Feb 2012 17:08:52 +0000 From: Tim Bray <tim at kooky.org> To: VoiceOps at voiceops.org Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites Message-ID: <4F2971A4.7000409 at kooky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 01/02/12 16:25, Darren Schreiber wrote:
Hi folks, I'd love to hear some stories (good or bad) of hosted PBX VoIP installs on 100+ seat sites (single site). Specifically if you've done this with Broadsoft or another solidified switch. I have mixed opinions on how this type of scenario can be successful and now I'm being pressed by a client on a formal opinion. I figure having it based on experience from others on a similar product is worth hearing about.
Specifically curious about how you addressed call quality issues and ensured bandwidth and uplink were sufficient.
I help look after a site with 140 ish SIP phones on the same site. Works very well. Phones all on www.voipfone.co.uk The sums for network links are easy. Bandwidth per call * calls. Then spec the right circuit. Things people forget: 0) To plan the user experience. You can just slap a new phone on a desk and expect people to use it. You need to do training for end users. Even if you show them how to make a call. Do not tell the end users it is voip. Just `A new phone system`. 1) IP header allowance in bandwidth sums. RTP, UDP, IP, then Ethernet or ATM depending on the circuit. 2) Consider Packets per second through the router/firewall. VoIP is lots of small packets. Many firewalls have a low session count limit. a 25$ router is not going to cope with all those phones. 3) Just buy enough bandwidth 4) Protect the ethernet infrastructure. You want to be using managed switches which can - drop rogue DHCP servers - drop a port if somebody pretends to be the default gateway - cope when somebody makes a loop in the network or attaches a device which floods then lan with broadcasts 5) Put the Router in a HA setup with 2 routers and 2 WAN connections. With VRRP or CARP or similar. Or agree with the customer in writing that if the WAN fails, the phones fail. - or sell divert to mobile as part of the solution. 6) Manage all the phones on a configuration server. Lock all the phones down so people can't mess with them. 7) Don't use wifi to connect phones. 8) Avoid Active SIP ALGs. You don't want anything modding SIP packets on the router. Passive devices which detect SIP to do traffic prioritization are ok. Anything which modifies packets is bad. - Sometimes the SIP aware routers get hacked. 9) Don't use low rate codecs. 711 all the way. Or 722. 10) Primary and failover DHCP and DNS servers onsite. Tim ------------------------------ Message: 2 Date: Wed, 01 Feb 2012 09:12:05 -0800 From: Jay Hennigan <jay at west.net> To: voiceops at voiceops.org Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites Message-ID: <4F297265.5080505 at west.net> Content-Type: text/plain; charset=ISO-8859-1 On 2/1/12 8:25 AM, Darren Schreiber wrote:
Hi folks, I'd love to hear some stories (good or bad) of hosted PBX VoIP installs on 100+ seat sites (single site). Specifically if you've done this with Broadsoft or another solidified switch. I have mixed opinions on how this type of scenario can be successful and now I'm being pressed by a client on a formal opinion. I figure having it based on experience from others on a similar product is worth hearing about.
We have done several with Broadsoft.
Specifically curious about how you addressed call quality issues and ensured bandwidth and uplink were sufficient.
It's pretty much the same formula as with smaller sites. As a rule, an office with lots of phones also has need for lots of data bandwidth. Some times a larger site is easier. Customers that have an office with 100+ employees understand the need for redundancy and high availability more than those with smaller offices. This allows us to provide two diverse circuits for failover and run the VoIP over one and data over the other. Only in the event of a failure of either link does QoS come into play. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ------------------------------ Message: 3 Date: Wed, 1 Feb 2012 10:33:26 -0700 From: Carlos Alvarez <carlos at televolve.com> To: Tim Bray <tim at kooky.org> Cc: VoiceOps at voiceops.org Subject: Re: [VoiceOps] Experiences with VoIP and 100+ seat sites Message-ID: <CAFn1dUGM0E6NHPw7Urh_CqaDAB2nP7x9YK6vcOsj3Cjx6K3H0w at mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Wed, Feb 1, 2012 at 10:08 AM, Tim Bray <tim at kooky.org> wrote:
9) Don't use low rate codecs. 711 all the way. Or 722.
I completely disagree. Most of our customers are on g729 and nobody was able to hear the difference when we tested that versus 711. -- Carlos Alvarez TelEvolve 602-889-3003