Posts Tagged ‘cable’

postheadericon Are You VoIP Ready? – What Stable Connections Look Like

Figure 5 is a good example of a connection that should work for your VoIP application. In this screen shot, showing a 24 hour segment, you can see that there are only a total of 5 samples that go into the yellow area. The vast majority are in the lower middle of the green band with the average latency at 73ms and jitter of 4ms. As such, I would tell the customer that this circuit meets my criteria of VoIP readiness. The only thing I do not know for sure is how much bandwidth they have. Sometimes the customer will know and other times they will think  they know. If it is a T-1 connection, then you can be fairly certain that you are getting 1.54M up AND down and base your voice session calculations off of that. If it is a DSL or cable connection, you will most likely experience swings in latency as usage (voice and data) goes up.

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? – Bandwidth

Bandwidth -
When measuring your needs and potential use for VoIP you need to understand the type of compression (aka codec) your device (eg. your PBX) is going to use. The three most common types are g.711, g.723 and g.729 and it essentially refers to the number of samples of your voice
the device is going to send over the wires to the far end.
G.711 uses the highest sampling rate and consequently uses the highest amount of bandwidth - typically 80k to 90k per session (or per conversation). This means that over a T-1 connection (1.54m of bandwidth) you will be able to sustain 16 simultaneous conversations or voice sessions. Most VoIP services like Vonage state in their contract that the user understands that they will have to have at least 90k to sustain a VoIP conversation (implying a g.711 compression). In theory, you get the best voice quality (you will see this often referred to as Toll Quality ) with this codec and for the most part that is true. If you intend to run faxes or dial-up modems over this connection, g.711 is about the only way to go (there are some exceptions to this but not many).
The main down side to this compression, of course, is the bandwidth requirement. If you have off site users (the CSR agents working out of their homes, for example) using a DSL or cable connection, this could be an issue because you need the 90k for inbound AND outbound audio.
For these type of circuits, the downstream speed (i.e. packets coming to you from the Internet) is usually much greater than upstream speed (packets you send to the Internet). I often hear from end users that they get 3M up and down from their provider for $40/mo but upon closer
inspection, their contract actually says something like … you may experience speeds UP TO 3M …  which usually translates into something like 700k down and maybe 256k up on average – if that.
G.723 and g.729 codec sample rates are much lower and therefore use much less bandwidth. Typically, g.729 will consume about 40k per session and g.723 will be as low 23k. Most devices will offer g.729 along with g.711 and some offer all three – there are others (g.726,
g.728 etc) but you will only have know about those if you are going to study for your CCNA. Between g.723 and g.729, I personally prefer the latter – the sound quality is very close to g.711 and is great if you have a half way decent Internet connection and do not need to run a fax or
modem across it. G.723 sounds a little thin  to me and is usually accompanied with low volume. This is the compression that people commonly experience when they are calling support centers in India or the Philippines.
About 5 years ago, codecs like g.729 and g.723 use to add about 20ms to 30ms of latency which would have been a problem if your latency was already high – say 110ms or higher. Now it is almost a non issue with some of the Cisco routers that most of the carriers are using to offer
Figure 3 shows an elusive hardware configuration issue. The packets were doing well up to the last hop which was the customer s gateway where they were experiencing 10% packet loss at the point of the sample (next to the red triangle on the time line). The hardware was fine but as it turned out, the router had it s clock source set to itself instead of getting it from the ISP. As you can see, once the problem was corrected, the packet loss stopped altogether.
convergent solutions of voice (with built in QOS), data and MPLS. Symptoms of a bandwidth problem, unfortunately, are reported to the IT department the same as latency problems (which are of caused by bandwith problems) and from my field experience, they usually are. As the users will put it – It does not work …  and they won t care what the cause is and usually won t try to distinguish. The voice will be choppy, unintelligible or simply gone. Low volume is usually not a bandwidth issue but more often the result of the type of compression being used or configured. In the case of bandwidth saturation, as illustrated in Figure 2, your voice packets are likely to get delayed or lost altogether unless they are prioritized. If the saturation is really severe, you will probably experience poor voice quality even with QOS. In such cases, get more bandwidth!