An Important Voice

Sat, 1st May 2010

FYI, this story is more than a year old

Loading it up A predictable effect of implementing a VoIP business solution is additional load on the local network. Any IP implementation adds to the amount of traffic on the LAN (local area network); VoIP is no exception. There are ways to minimise the amount of potential congestion, and there are ways to assess the effect of the new VoIP implementation on the LAN. The techniques for minimising potential LAN congestion involve tracking where congestion may occur. It is commonly found: 1.Within a broadcast domain or, 2.An uplink between switches. To lessen congestion within broadcast domains you can alter the network topology. Before this is done, it is a good idea to get an accurate network topology diagram. Then by working from a realistic representation of the client’s network, some solutions may be applied:

Implement a VLAN to logically break up the large broadcast domain to smaller ‘virtually independent’ LANs
Build a physically separate network, joining the client’s LAN only at a useful point, which would be dependent on the amount of IP interaction needed between the networks
Use a router (or multilayer switch) to separate the LAN’s broadcast domain, while allowing IP communication between the networks. This is useful where the pure size of the added IP PBX is considerably increasing the level of broadcast traffic on the LAN. If a potential bottleneck is identified in the existing topology, for example several switches cascading to the router or server/storage area, then additional structured cabling may fix the bottleneck. If the issue is simply the amount of throughput reaching the switch port limit, aggregating switch ports by connecting several ports between the switches to enable combined load sharing will work; for example 4x 100Mbps ports to equal a 400Mbps link between switches. Another option is to use switches with gigabit uplinks, or fibre uplinks for gigabit switches. Quantifying the extra load on a network is not a quick process. It will generally require benchmarking the LAN for some time before installing the IP equipment. Benchmarking needs to be done at a variety of times and days, as users’ habits typically vary day to day and hour to hour. Once you have a clear picture of the traffic density on the network, you can compare it with the traffic after you have installed the IP PBX (or other technology) to gauge the extra load it has added to the LAN.

Get predictable As well as a predictable impact on the network, there may also be an unpredictable element! This usually involves a new technology or protocol being used in the network which, for whatever reason, the existing network may be vulnerable to. For example, many VoIP solutions use multicast to more efficiently send data across a LAN; however, some switch features may inhibit the correct multicast operation until they are explicitly configured. It is fair to say that the single biggest pitfall is the lack of a good, up-to-date network topology diagram. Most of us relate better to a diagram than a written specification for pretty much anything. Unless your customer is IT-savvy, the installer will be forced to build his own interpretation of the network. This approach is error- prone, as much is ‘hidden’ within network device hardware and costs the installer time. It also moves responsibility for the network too much into the installer’s domain. VoIP and unified communications VoIP: this simple acronym covers a plethora of devices and technologies, from Skype to fully managed networks using proprietary IP devices. Several years ago, I read that there are as many different interpretations of unified communications (UC) as there are UC vendors. Even now, I don’t see much has changed. Microsoft promotes server- and PC-based UC solutions, Cisco promotes router- or network-based UC solutions, large software development houses and ISPs promote cloud UC solutions, while IP PBX vendors promote networked specialist communications device solutions! The best way to analyse the different UC solutions is to treat each as a separate communications proposal, and see how they fulfil certain criteria:

Is the product support, from vendor to distributor through to reseller and installer, excellent?
Will it fulfil the business needs of the client that the current system cannot?
Compare the future-proofing required by the client versus how much the UC product offers.

Introducing SIP SIP (session initiation protocol) is a strong agent of change for our current telecommunications environment. Like the implementation of IP networking, much of the initial uptake of SIP is cost based. SIP is available to small and medium businesses, just as it is for the enterprise space. Using ADSL, many existing business systems can connect SIP trunks without lots of expensive hardware. Naturally there is an element of you get what you pay for. While ADSL is a mainstay for small business internet access, it is not suited to VoIP. There is no mechanism in place to allow VoIP to proceed with good quality in the contentious (from a bandwidth usage point of view) ADSL environment. Keep in mind that the limiting factor is the upstream bandwidth of ADSL which causes the bottleneck. If very little data is in use across the ADSL connection, then VoIP will probably be okay, but it is not possible to assure the quality of voice. More appropriate broadband technologies can be found. Some purely offer more bandwidth (VDSL comes to mind, with good downstream speeds and relatively high upstream speeds). Some ISPs are offering SHDSL technology, which has the advantage of being synchronous – having the same up and downstream speeds. And some ISPs offer this sort of service with management included (often using a DiffServe setting to identify the voice data and give it special treatment of some sort), which ultimately ensures some level of quality for VoIP. Look out for SIP’s future offerings, which will probably grow into a bewildering array of features. Luckily for those implementing a VoIP solution, New Zealand is somewhat conservative in its current level of SIP functionality; however, overseas trends indicate this will not last. A major strength of SIP is the way the protocol lends itself to being built on, enabling the facilitation of new features not yet envisioned. This, however, means increased complexity, but you’ll find that if you put some effort in to keep current with the ISPs’ SIP features, it will prove useful.

Share on: