Am I taking the easy way out if I separate VOIP network?

[trevm999]

At my work we currently have a digital phone system and are looking to go IP. We have CAT6 drops to about 95% of our phones. The telecommunications companies say it is best to put the IP phones on an isolated network. But from what I've read online, network specialists say that is just taking the easy way out, and it probably only the best solution for 20% of SMB, most of the time it is better to get QoS configured correctly on the network.

I don't have much experience with configuring QoS, so in that sense it would be easy to me to have them separate. But I don't just want to take the easy way out and I don't have a problem with learning new things. It also sounds nice to be able to add phones quickly in the future by just adding a switch and a PoE injector, but I also feel that is not very neat and I would probably want to run lines for long-term solutions.

We would be looking to have about 50 IP phones, and we have about 125 devices connected to the network.

 

[Markverhyden]

What exactly do you mean by isolated network? Completely down to the ISP connection? I've setup a number of VoIP systems. None my design. Also have been in several environments using VoIP as an EU.

Maybe 50% had separate lines run for some, not all locations have a computer, or all of the phones. Personally I prefer to have separate runs for each device. That way if there is a problem with a run you can just daisy chain. I would not use a switch dedicated to just VoIP as that also reduces redundancy. But the biggest thing is QoS. Especially if there are machines that are bandwidth hogs like workstations processing video.

 

[nlinecomputers]

But I don't just want to take the easy way

Why the heck not? Seriously? IP phones are a pain and bandwidth hogs in my experience. Isolation is better. Separate ISP lines if can just so that having the internet go down doesn't kill both web access and phones.

 

[trevm999]

So there are a couple options we are looking at. If we stick with our current phone service provider we would either still use the analog lines we have now or create a PRI Megalink. If we switch to our ISP for phone service we hope to be using SIP trunking over the same connection (fibre) but keep a couple analog lines as a backup. Either way the PBX will get still connected to our router.

I suppose that with SIP we would still be looking at setting up some kind of QoS to prioritize the SIP trunks over other traffic...

Also, we would be getting two PoE switches if we kept the voice CAT6 lines separate.

 

[fencepost]

Separate runs for the phones makes plenty of sense, and despite what Mark said you might want them on a separate switch - because then you can just get a good 48-port PoE switch (or 2 24-28 port ones to avoid complete downtime if one fails) to cover most of the phones. I'd expect to have a connection between the networks, but if the bulk of the phones and the phone system are on dedicated equipment then they should have minimal impact on the rest of the network because all of their traffic will remain on those switches. For the scattered cases where there's no dedicated line and you have a computer piggybacked, those will still work no matter where they're connected; similarly if you have a computer and end up with it on the phone switches it shouldn't have a major impact.

 

[trevm999]

I liked the idea of having the best of both worlds, but is just separate switches enough? Should I also have the PBX as the DHCP server for the phones on the PoE switches?

 

[Digital Micro]

I used a Ubiguiti Edge Router Lite for the only client I have with a VoIP system. You can separate two internal lans very easily.

 

[fencepost]

I liked the idea of having the best of both worlds, but is just separate switches enough? Should I also have the PBX as the DHCP server for the phones on the PoE switches?

I'd be careful with that. Are you going to have the phones actually on a separate subnet? What I was talking about was a single subnet, but due to the way switches pass traffic if the phones and phone server are connected to the same switch that traffic will never cross to another switch - remember that it's not a broadcast network so packets generally move directly between the relevant ports only.

Multiple subnets is not a problem, but you'll want to be a bit more careful - I've not played with separate DHCP pools for equipment differentiated by MAC address range, so I can't really advise you on how to best do it.

 

[TouchToneTommy]

If you are going to combine phones and computers on the same wire run, you will want to set up VLANs for data and voice. The native VLAN is set to data, and an option string is added to the DHCP server to tell the telephones which VLAN to switch over to, and then a separate DHCP for the voice VLAN, which can be the PBX itself, if you will still have that on site. You can also use switches that use LLDP to get the phones onto the proper VLAN.

Another way is to use separate wire runs for phones and computers, and not have the 2 networks connect to each other. We do this with our PBX which has 2 separate Ethernet ports. One connects to the Data network, to be able to send out voicemail-to-email or use the proprietary smart phone app to make calls over the pbx, and the other Ethernet port connect to the voice-only network, the PBX acting as DHCP server to the phones, no QoS needed.

By still having a PBX on site, allows you to combine digital telephones, analog telephones, VoIP and SIP phones, with telephone company services like PRI, SIP, and analogue trunking.

 

[trevm999]

Another way is to use separate wire runs for phones and computers, and not have the 2 networks connect to each other. We do this with our PBX which has 2 separate Ethernet ports. One connects to the Data network, to be able to send out voicemail-to-email or use the proprietary smart phone app to make calls over the pbx, and the other Ethernet port connect to the voice-only network, the PBX acting as DHCP server to the phones, no QoS needed.

So this was how we were going to do it, since we mostly have separate runs anyway.

Does a hardware IP phone connect to the PBX differently than a softphone? If it doesn't, then couldn't you also hook up a hardware phone on the data network in a pinch? If it was more than just temporary, I guess you would then need to set up QoS, but wouldn't you want to set up QoS for the softphones anyway?

 

[fencepost]

By "softphone" do you mean a SIP client running on a PC? If so, then you wouldn't be able to VLAN those off since obviously it's the PC's network connection that matters.

What I was describing with PoE switch(es) for the bulk of the phones and the phone server, plus a connection over to the switches for the PCs would basically be one big network, so yes you could connect phones (or PCs/printers for that matter) to any port. Having the bulk of the phone traffic on its own switch(es) would avoid most of the need for QoS for the phones since they'd all be in their own separate area; traffic between the phone switches and the other network infrastructure would likely be minimal except for whatever there was from phones or PCs connected to the "wrong" switches. That's for the internal phone connections.

For the external connections (SIP or IAX2 trunking) you'd likely want QoS and a capable router, or a separate Internet connection. The ideal might be separate Internet connections on different carriers, with phone traffic routed out through one by preference and all other traffic out the other. If you had things configured correctly that could give you some level of failover (with a risk of bad phone quality) - or at least a way for you to connect in even if one connection was down.

 

[trevm999]

By "softphone" do you mean a SIP client running on a PC? If so, then you wouldn't be able to VLAN those off since obviously it's the PC's network connection that matters.

Yes, that's what I mean (I think). But couldn't I enable QoS to prioritize that traffic on the network?

 

[fencepost]

Yes, that's what I mean (I think). But couldn't I enable QoS to prioritize that traffic on the network?

QoS would certainly make sense if it was leaving the network (e.g. if it's connected to an outside SIP provider), but if the phone server is within the same LAN then I wouldn't bother - if you have problems that QoS would address on an internal LAN, then you have some serious saturation issues and QoS is likely to be an ineffective band-aid on the real problem. Caveat: unless you're in an environment that involves a lot of moving large files around - if you're doing video work and running a SIP phone on the same network connection you may have issues.

Edit: If you think about it, QoS really only matters when the network connection is saturated because at that point it can prioritize packets. In the setup you're talking about, that would mean prioritizing packets coming from the phone server higher than packets coming from file server(s), so that the SIP packets get sent down the fully-saturated connection first. If you have a fully-saturated connection at that level, either you have some impressive file server throughput to that one workstation or you need to upgrade to Gigabit.

 

[TAPtech]

It depends on the environment really. Typically, if you have gigabit networking, and under 10 IP phones... I would only use a separate network if the infrastructure is already there. If the client needed to purchase new gear to make it happen, I wouldn't even recommend it. A decent router with proper QoS would make easy work of this and isn't as complicated as it sounds.