How does VoIP performance differ over LAN, WAN and other networks?

Will VoIP behave differently over different types of networks -- i.e., over a WAN, LAN, VPN, and the like? If so, how does voice traffic handle in these environments?

Yes, VoIP can and often does perform differently depending on the environment. Results vary, and this is where you need to pause and think about how VoIP best fits in to your environment.

VoIP over the LAN should be the easiest. This traffic will be intercom (station-to-station calling) and minor keep-alive and will display the date and time of broadcast traffic to your phones. This assumes that you have on-premises gear, such as an IP-PBX, but if you are using hosted services it depends. Some hosted solutions require your local intercom traffic between stations or extensions on the same premises to route across the WAN. Other providers have gear on-premises that allows connectivity between MAC addresses after an initial connection is made over the WAN.

Where performance could become an issue is either with the link, prioritization or lack of Quality of Service (QoS), and whether or not you've deployed VLANs.

When the voice traffic leaves the LAN, the next hoop to jump through is getting a handle on where the call goes. MPLS networks are equipped to handle real-time traffic. If your WAN isn't MPLS, then you may be dependent upon broadband, and this is subject to time-of-day traffic since you will be competing to share bandwidth (across a cable network, for example). Latency often increases and voice traffic is impacted since the MOS scores may dive while user complaints increase.

In non-MPLS networks you can implement G729a as first choice if your provider is capable, and then revert to G.711 if the call will not negotiate to the lower bandwidth. This includes GRE tunnels deployed in a mesh network in regards to VPN. But VPN means different things at different times. It's important to note that, if your VPN is a mesh connection to a data center or hosted provider, you will need to consider leveraging more bandwidth (assuming you don't have MPLS).

For VPN connections serving telecommuters you need to determine that you have the available resources. This includes some sense of the telecommuters gear and bandwidth. You can still implement QoS for outbound side of traffic headed over broadband. Another good way to leverage voice is to use SIP trunks if your gear (gateway or PBX) is "certified" or has been tested against the provider's requirements. If this is the case, you can expect a pretty consistent service.

Windstream, for example, offers an MPLS service along with SIP trunks, and their voice traffic rides over their private network so users can, or at least should, expect a better experience than riding over the public Internet. Another example is Verizon FiOS, which performs really well with VoIP. Comcast and other cable TV networks are competing with residential services and TV demands. In addition, I think the Verizon FiOS network just performs better than cable operators. They both work but operate differently. In hybrid networks, where you utilize broadband as a backup route, consider using G.729a as your first choice to preserve bandwidth for your data applications, unless of course your business model is voice-centric and doesn't have a significant dependency upon data applications.

Hosted providers with a soft switch located in California and customers in Virginia don't really have an ideal configuration. How many hops do Virginia users go through at different times of day to reach California? In any public Internet voice solution there's also the issue of time-of-day traffic, such as at 5 p.m. EST. If our SIP trunks' audio quality is an issue, then it's usually because of competing residential traffic and increased traffic in other parts of the country. All of which we have no control over.

Until the Internet grows QoS, VoIP will not be ideal for this type of environment. But just because it is an ongoing challenge does not necessarily mean it must be avoided.