Posts Tagged ‘router’

postheadericon Are You VoIP Ready? – The “X” Factor

One X factor you will need to consider when looking at a VoIP solution is your network s vulnerability to viruses, worms and Trojans. The first thing I caution customers about when they want to go all out and purchase a pure  IP telephony solution is that as a general rule, you want to keep your local voice and local data traffic separate. In practice, this means if you already have a voice infrastructure (i.e. jacks specifically for telephone
sets that home run to a main telephone room or the IT Head End  room without connecting to the LAN wiring), put your voice on that with TDM sets instead of abandoning the wires that are in place.
Voice and data packets going out to other offices that are linked to you through a Point to Point or VPN connection will inevitably share time on the same Internet circuit. However, TDM sets are not affected by anything on the LAN until they have to connect to some off site device through VoIP. Regular local traffic such as voice mail retrieval, intercom calls, paging to the warehouse or calling a supplier over the PSTN will occur with or without a data switch or server in place.
If you do decide to go all IP, then do it when you can make a fresh wiring start and run a separate cable for voice and data sets. Also, keep the voice devices on their own subnet separated from the other LANs by a decent router. RonEK is not a Cisco reseller but we like their routers and recommend them in cases like this.
Many IT people would take issue with this approach but I have personally witnessed and been victim to what can happen as shown in Figure 4. As you can see, everything looks great until the main server on the LAN was hit by a very aggressive virus. For about 2 hours it created such havoc on the LAN in the form of broadcast storms that all network traffic was reduced to a crawl and VoIP was stopped cold.

postheadericon Are You VoIP Ready? – QoS (Quality of Service)

Normally, when packets are serialized out the router to the Internet, they are sent in a first come first serve  fashion. If your router is equipped with QOS, packets from your PBX or SIP server* can be prioritized ahead of the other non-voice packets thereby keeping the flow of
voice traffic relatively smooth. Most carriers that offer a combined package of voice and data services do just that. RonEK is a partner with several ISPs and one of the first questions on the vendor check list is the IP address of the PBX. Most of the higher end carriers will provide an
end to end managed circuit  which means that they can control the connection from your office to their space in the central office. From there, packets are routed out on their backbone or someone else s backbone depending on the carrier s capacity and the final destination.
Keep in mind that QOS prioritizes packets going out to the other end. Once a packet leaves your premise or your provider s backbone, it is no longer prioritized and subject to the winds and tides of the Internet just like all the other packets. So, when designing a multi-site
network, try to stick with one provider and, if possible, try to do it on an MPLS platform. Usually if you stay within a provider s backbone from end to end, the prioritization will be maintained throughout the connection. Also, there is no way to prioritize packets coming to you until they actually get to you. Many times customers think that if they simply implement QOS that all their voice issues will go away not realizing that they only addressed half of the potential problem. Your connection and QOS is just part of the overall voice session that YOU control. The rest is in the hands of the intermediary (often there is more than one) that controls the path of the packets and then finally, the ISP and equipment at the final destination.
* More about SIP servers in coming articles.

postheadericon Are You VoIP Ready? – Latency

Every IT staff member knows that when you ping something, in addition to confirming that a device is connected to the network, the reply will give you the round trip time in milliseconds from the device you are pinging. A ping is a type of ICMP packet (along with the commonly used trace route command) that you can use to determine just how much delay your packets will experience from point A to point B and back. All of the graphs you see in this article are latency based and bandwidth availability – or lack thereof – has to be extrapolated from that.
Realistically, there is no way to know how much bandwidth some one has by simply looking at their connection from the outside  unless you are
sitting in the Central office looking directly at the connection. That said, there are several things that latency will tell you. I usually try to get a week s worth of data before I m comfortable with the circuit – if there is a problem, it will likely show up within that sample.
The magic latency number I like to see when testing for VoIP usability between sites is 80ms or lower. Another term that is directly related to latency is jitter . Jitter is caused when packets leaving a source in a certain order and spacing, arrive at the destination in the same order
(usually) but with different spacing. It is essentially the difference in latency time from one packet to the next. When jitter is high – anything over 15% variance between samples – it usually points to bandwidth problem. To get an idea of the impact of high jitter, imagine the sound of an
audio CD that is played while alternating between pause and fast-forward. The garbled sound is characteristic of jitter.
If you are going to network offices within the same city, you should see ping times of around 30ms or less and jitter under 5ms. The further across the country you go, the higher the latency tends to get. As of this article, a typical ping time from Houston to Los Angeles is
between 54ms and 67ms. Surprisingly, latency from Houston to Hong Kong is only 62ms to 87ms. I was in Switzerland not too long ago and the ping time was only 75ms from Bern to Los Angeles. My point is that, while geographical distance is an issue, it is not going to be the
determining factor of whether your VoIP project is going to work or not. Things that will affect whether your voice packets will get there in reasonable time or not is QOS (which stands for Quality of Service), the ISP or Carrier, bandwidth, hardware and hardware configuration.
To get an idea of what mis-configured hardware looks like, take a look at Figure 3. The IT manager had just moved into a new facility and users were complaining to him about slow Internet speed. As you can see, the latency is pretty good but the amount of dropped packets was
very high. The poor guy spent the better part of 3 weeks arguing with the carrier about the problem. Their contention was that the source of the problem was at his end as they showed everything good when they tested up to the NIU. They also ran diagnostics on the router – that
they supplied – and that also produced nothing. Technically, they were right except for one important setting that would not show up on any diagnostic. The Clock Source  setting for the router was configured as Internal  – i.e. it was referencing itself as a clock source – instead of
clocking off the network (sometimes referred to as Recovered  mode). For the most part, it worked but any time the router or carrier s clock drifted slightly, packets would be dropped.

postheadericon Are You VoIP Ready?

If you are considering VoIP for your company – or more to the point, if YOU are responsible for the implementation of VoIP for your company – here are the basics you will need to understand.

Voice over IP performance is a function of:

a) Bandwidth

b) Latency

Both components have to be within a certain tolerance  in order to be usable and there are a multitude of factors that can adversely affect either. Many IT professionals who are first time VoIP-ers  often think that given enough bandwidth, you can do anything – including voice. This is only half true. A lack of bandwidth can cause latency, but an abundance of bandwidth is not a guarantee of a clear conversation. Of the two, latency is not only a show stopper, it is also the hardest one to find and correct because there are many causes that are often times not within your control. Figure 1 is a great example of a company with a bonded 6M T-1 connection with such erratic latency – and jitter  – that it is virtually unusable for

voice applications. In many cases like this, the most natural scapegoat is the carrier, however, in this case, hop 14 is the WAN side of the customer s router and hop 15 is a device behind it which implies a problem with the hardware. Here, the problem turned out to be one of the 4 T-1′s were in a permanent Admin Down  mode and needed to have the WIC replaced.

WARNING TO THOSE JUST GETTING INTO VoIP – Voice is real time  – using primarily UDP packets – and therefore much more affected by things like dropped packets, jitter and high latency than regular  data. If there are issues on your Internet connections with these items, you will probably not realize it unless you specifically – and continuously – test for it. Most carriers only guarantee bandwidth and NOT latency. Trust me, the CEO, CFO, Customer Service manager and Sales manager will get upset if the email server or Internet is a little slow, but they will absolutely FREAK if their phones don’t work.