Tom, You've already gotten some great advice. I have Mitel experience as a customer in an IT role supporting hundreds of end users. I grew up in the voice and cabling business, migrated myself career-wise into the data world, and then upgraded my position into the converged voice and data world. If you've got a validated CAT5e or better cabling infrastructure for your data network already, my advice is to leverage that and abandon your existing voice cabling infrastructure unless it is already certified with a Fluke/Ideal/Agilent, etc CAT 5e cable certifier (not one of those garbage cabling mapper tools that simply tell you that you've got the pinouts right per TIA568B). I'm talking about a $3,000 (or more) certifier that will tell you cable length, attenuation, etc.
If you don't have a truly validated data cabling infrastructure already, well, ummm.......good luck? In my last position (which I just left in early March of this year) I implemented my first Mitel SX-2000 in January of 2002. We later (in 2005) converted it to and IP/TDM system via a controller upgrade to the 3300 platform, with the SX-2000 TDM cabinet acting as a peripheral node so that we would not have to replace all of the handsets. Mitel is proud of the fact that in order to get to "the next level" that you'll be able to re-purpose 60% or more of your existing hardware without having to forklift - at least that used to be one of their claims to fame, and it held true for us. Since that conversion in 2005, I've since implemented 2 additional conversions from SX-2000 based controllers to 3300 series controllers, as well as 3 additional native 3300 controllers with 5200 and 5300 series IP phones. All of my closet switch infrastructure was Cisco Catalyst 3560 and 3750 series switches, and I NEVER had one problem with voice quality. All in all, I probably had between 350 and 500 handsets on the Mitel platform, about 50% of which were natively VoIP. Where I had VoIP phones, I only had one data drop, and had Laptops, Desktops, and Printers running from the back of the phone (Though I never tried connecting a switch to one. In my opinion, that in and of itself is asking for trouble). Rarely did I have a hiccup that required a phone reboot; not often enough that it was considered an issue. Being in healthcare, there was not a high tolerance for hiccups with phones, so if we had seen significant issues with VoIP, we would not have continued down that path. As for VoIP over MPLS T-1 lines, I'm doing that now with hundreds of handsets in more than a dozen facilities across the continental US, and not seeing a problem. It is Cisco instead of Mitel, but a data/voice packet is a data/voice packet....qos has to be right for it to work. I had two vlans setup, one for voice and one for data. Setup properly, you can have your PCs plugged into the back of the phone and they will still get an IP for your data vlan and your phone will have a voice vlan IP. qos works great if configured properly. I see absolutely no need to physically segregate voice and data in most scenarios. They coexist just fine 99.5% of the time. Unless you have some supremely unique needs, I don't know that I would be able to justify the switching and cabling infrastructure requirements of keeping your voice and data segregated. Something to consider is that you need to have a solid DHCP infrastructure, preferably with a central point of administration, IMHO. Originally, we had our switches and PIXes at each site doing DHCP. Ultimately we moved to Windows Server 2003 for the ability to centrally manage and administer our exclusions and vlan IP addressing. You'll definitely need to know all of the required DHCP options for Mitel (128 and 130 come to mind - I think there are a couple more, but I'm drawing a blank right now). Oh wait.... http://lmgtfy.com/?q=mitel+dhcp+options :-) Finally, you do NOT have to forklift your switches or buy a bunch of power bricks for your phones if you don't already have PoE switches. You can buy a powered multi-port midspan from someone like PowerDsine (now part of Microsemi). They've been around for years, and came recommended to me by a major Mitel partner. Though I never had the need, they were my plan B if I ever needed power where I didn't have a powered switch. http://www.microsemi.com/literature/PowerDsine%20Midspans.pdf HTH, Jonathan, A+, MCSA, MCSE On Mon, May 2, 2011 at 3:03 PM, Tom Miller <[email protected]> wrote: > Thanks folk - I am more educated already. For you Mitel folks, what sort > of VLAN/QoS did you configure on your switches. Looking at my switches, I > see there are already a number of VIOP vendors built in for QoS, but not > Mitel, so I'd need to add it. > > > >>> "Stringham, Steven" <[email protected]> 5/2/2011 1:21 PM >>> > > Tom > We have a Mitel 3300mxe phone network with 5340 phones on the desks. We put > this in about 4 years ago. > > I replaced the older switches with 3560 POE switches and have the PCs > behind the phones. We are able to put microswitches behind these (so you > could have a PC and a printer, etc.). > > We have had some issues with phones acting up, so that we got bad > throughput at the PC. Replacing the phone takes care of that. Spares are > important. > > Getting phones with a completely digital display is wonderfull. I am so > glad not to have to print out templates for phones anymore, because it is > all on the display. Select your phone carefully. > > We have 8 sites across our MPLS network. Some smaller sites (across T1s or > even DSL VPNs) are being hosted by a 3300mxe on the other side of the wan. > Communication is great. Max latency is about 40-50, sometimes as high as > 100ms when in high traffic. Voice is still good. One of the capabilities of > Mitel is having a phone across the internet (for example - having a phone at > home on your main switch). This works very, very well. > > I absolutely agree - get good POE switches, and put decent UPS units > supporting those switches. Also be very careful on your switch/phone > selection. Different POE devices support different power draws. There are > several standard levels of power draw. Some POE switches will support a > maximum power draw. For example, the 5340s take about 6.1 watts. The ports > on my 3560 support 15.4 watts. However, my 48 port switches will only > support 24 ports at the full 15.4 watts. But, it can take the full 48 ports > at 6.1 watts. If I put GigE phones in, they would take the 15.4 watts level > - so I could not put a full compliment of phones on my 48 ports switches. > > Good Luck > > > ------------------------------ > *From:* Tom Miller [mailto:[email protected]] > *Sent:* Monday, May 02, 2011 6:39 AM > *To:* NT System Admin Issues > *Subject:* VOIP design questions > > Folks, > > We are planning to retire our current phone system and move to a Mitel VOIP > system. Not having implemented VOIP before, I have some questions for those > of you that have: > > - our vendor claims our current data network can easily handle VOIP traffic > since it's a small amount of traffic (don't know exact amount yet, still > awaiting vendor response). As such, they tell it is possible to use our > current network to accommodate voice and data. I'm not sure if I"m > comfortable with this. I was thinking of a more segregated approach: > different network and voice and data never intersect. > - our vendor claims we can use the existing data jack for the phones, and > plug the desktop PCs/laptops into the phone as a sort of switch. I'm > thinking this would add another level of complexity: phone is broke and by > the way you can't get on the network now. > - the reason the vendor suggests the above is that the current voice drops > (cat5) terminate to phone patch panels (in most cases). Those cables would > need to be cut and re-terminated to switches. > > So I have some concerns about our vendor claims. The dollar figure they > propose does not include network changes, new switches, etc. Looking at the > cost proposal, I am thinking there are quite a few hardware and man-hours > costs missing. > > What do you folks do for VOIP? > > Thanks, > Tom > > Confidentiality Notice: This e-mail message, including attachments, is for > the sole use of the intended recipient(s) and may contain confidential and > privileged information. Any unauthorized review, use, disclosure, or > distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > > > ------------------------------ > > For more information about *Lewis and Roca LLP*, please go to * > www.lewisandroca.com* <http://www.lewisandroca.com/>. > > Phoenix (602)262-5311 Minden (775)586-9500 Tucson (520)622-2090 > Albuquerque (505)764-5400 Las Vegas (702)949-8200 Silicon Valley > (650)391-1380 Reno (775)823-2900 > > This message is intended only for the use of the individual or entity to > which it is addressed. If the reader of this message is not the intended > recipient, or the employee or agent responsible for delivering the message > to the intended recipient, you are hereby notified that any dissemination, > distribution or copying of this message is strictly prohibited. If you have > received this communication in error, please notify us immediately by > replying to the sender of this E-Mail by return E-Mail or by telephone. > > In accordance with Internal Revenue Service Circular 230, we advise you > that if this email contains any tax advice, such tax advice was not intended > or written to be used, and it cannot be used, by any taxpayer for the > purpose of avoiding penalties that may be imposed on the taxpayer. > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > > Confidentiality Notice: This e-mail message, including attachments, is > for the sole use of the intended recipient(s) and may contain confidential > and privileged information. Any unauthorized review, use, disclosure, or > distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > -- Jonathan, A+, MCSA, MCSE ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
