You need a basic understanding of how networks function if you want to grasp all the potential sources of latency. Fortunately, network engineers created a theoretical structure that encompasses all the individual variables on a network, which your network engineer can use when designing, configuring, implementing, and troubleshooting a network.
If you already know the Network OSI model, glance over this section for anything interesting. If you’re diving in to VoIP and your resume currently covers all the intricacies of standard telephony voice calls and nothing on LAN design or management, then today is your lucky day — you get to find out all about the OSI model.
VoIP has more components to it than standard telephony. A traditional telephony environment has a limited number of variables that potentially affect call quality or completion. Traditional telephony generally has to concern itself with
The physical lines carrying the call The hardware that the call encounters
The hardware and physical lines can both experience layers of problems, but in a traditional telephony environment, the specifics of those problems fall on the shoulders of the companies, carriers, and vendors that own those phone lines and that hardware. Traditional telephony requires an end user to be responsible only for his or her phone system and any inside wiring. After you clear these elements as potential sources of a problem, everything else that can go wrong on a phone call is someone else’s problem.
VoIP brings the finer details and responsibilities, previously shouldered only by carriers, right into your company. Not only can you have static on a call generated from a wire that has an electrical short, you now have to take responsibility for many other layers of interaction between yourself and your VoIP provider where trouble can arise.
You need to ask yourself about any potential trouble issue, “What are the variables?” With VoIP, every interaction between your hardware and your VoIP provider is a variable. You still have to consider the potential for problems caused by the physical line, but now you also have to concern yourself with how the packets are sent and received, bandwidth use, allocation, the banter back and forth of SIP methods and responses, SDP, and RTP transmissions.
Network engineers and developers use the Open Systems Interconnection basic reference model (OSI model) as a standardized way of talking about the components required to support all network transmissions:
Good news: The OSI model is broken down in a logical hierarchy that you can easily grasp.
Bad news: Latency on a VoIP call can be introduced at any level of the OSI model.
Figure 5-5 shows how the model is divided into seven layers and how those layers identify the protocols used to transmit VoIP. Each layer of the model is identified by the job it performs in a transmission and relies on the layer below it for support while supporting the layer above it. The model is also used to develop applications that can exist and be modified at higher layers of the OSI model that don’t require corresponding changes on lower levels.
Figure 5-5:
OSI model with VoIP.
On your computer at work, you might be running Windows XP as your operating system, which supports the higher OSI level Microsoft Internet Explorer application to surf the Web. If you choose to use another Web browser, such as FireFox, that exists on the same application layer of the OSI model, you can easily download and use it from the same computer without having to change the operating system. The ease in which you can change higher OSI level applications without needing to manipulate the supporting software in the lower layers shows the support structure and flexibility of the OSI model.
Entering the first layer
The first layer of the OSI model is the Physical Layer — the part of the network you can actually touch. It’s the wires, cables, connectors, and fiber used to string together all the elements of the network. This layer handles the electrical signal, mechanical connections of the connectors and jacks, and voltage specifics.
Electrical shorts in the cabling or hardware can appear in the first layer causing static, latency, and line noise on all calls, VoIP or non-VoIP. The slow failing of a hardware element in the call path usually causes issues on the first layer. The switch, router, or telephony hardware might have an electrical short that’s generating errors. Even if you had a traditional phone system, you’d still have to watch out for layer 1 problems.
Even if the first layer doesn’t have any noticeable defects or shorts, it still creates a small degree of latency. Transmitting any signal or message over hundreds or thousands of miles takes some time. If your calls are running half-way around the world, expect some distance-related latency.
Moving to the second layer
The second layer of the OSI model is also referred to as either the Data Link or Media Layer. This layer provides the most basic foundation for the transmission of packets through the LAN and is the portion of the OSI model where the header information in the packets being transmitted. It handles error control, synchronization, and flow control. In this layer, network switches function to direct packets. Because it’s a lower level of the OSI model, it generates less latency when handling packets because the packets aren’t opened and inspected or checked for prioritization before they’re sent along the LAN, processes that take time.
Network switches work at the second layer of the OSI model and are concerned with frame units, physical addressing (MAC) and signal attenuation. Any challenges with the responsibilities of the second layer can cause latency, jitter, and packet loss.
Sending IP on the third layer
The complexity of the interaction between the packets of data and the hardware supporting them increases when you progress to higher layers of the OSI model.
The second layer has minimal interaction with the data, which allows network switches working at that level to process packets of data very quickly. This cursory interaction has a downside: the network switches can’t perform advanced or complex routing at a per-packet level based on any specialized criteria such as prioritization.
The third layer of the OSI model is also called the Network Layer, which increases the level of hardware interaction with the data packets. This layer of the OSI model uses network routers as its primary hardware devices for processing packets. These routers are responsible for setting up the connections from end to end, keeping them active for the duration of the call, and tearing them down after the transmission is complete. Just like the second layer (which I talk about in the preceding section), the third layer can cause packet loss, jitter, and latency, but the third layer has the added variable of being susceptible to amplification and distortion issues in the media that can result in echo being heard on the call or variations in volume.
Transmitting UDP on the fourth layer
The fourth layer of the OSI model is called the Transport Layer. This layer is responsible for end-to-end connections, including flow control and error recovery. In a normal Internet circuit that runs TCP/IP, you’d find TCP (Transmission Control Protocol) in this layer. VoIP doesn’t use TCP, but instead employs UDP (User Datagram Protocol) as a leaner alternative.
The packets sent by UDP are called datagrams and contain both a header and payload information. The datagrams are sent as efficiently as possible, but you get no guarantee that they’ll arrive in sequence — or at all. As long as you and your carrier are managing your networks effectively, UDP transmits VoIP calls without any problems because it’s faster than TCP.
In this level of the OSI model, the RTP (Real-Time Transport Protocol) also does its work to transmit and receive the media of the VoIP calls. It uses support from the UDP at this same level (it also gets support from the IP in layer 3 to make it all work).
This level of the OSI model is susceptible to packet loss and jitter. It also bears the additional challenge associated with transcoding distortion while packets are converted into and out of UDP that can cause the voices being sent to sound robotic.
Topping it off with the Session, Presentation, and Application Layers
The top three layers of the OSI model involve a much higher level of interaction at the individual packet level. topics 2 and 3 cover the detailed aspects of interaction between transmissions at these levels.
When the SDP interacts at the fifth layer of the OSI model, also called the Session Layer, communications between servers or PCs take place at this level, such as when you dial in through your company network to access your work PC remotely from your home. This layer provides the management structure for communication between applications and sets up the sessions used for VoIP, including most of the tasks performed by SDP.
The sixth layer of the OSI model is also called the Presentation Layer. It houses data representation and encryption. In this layer, data is compressed, decompressed, and encrypted, if needed. The audio of a call is also encoded into or decoded from VoIP.
This layer has inherit latency because it takes time for your codec to convert the data. In this layer, VoIP calls are transcoded from one codec, such as G.729, into another codec, such as G.711.
The highest layer of the OSI model (layer 7) is the Application Layer, where servers provide services for network management and SIP functions. This layer also contains the mechanics for converting sound into packets, and it may introduce additional noise on the line. This noise can be either
Additive noise: For example, additive noise occurs when your VoIP hardware attempts to convert a louder-than-expected sound or sounds in the sampling algorithm. If the volume of sound from background noise is too great, you have additive noise.
Subtractive noise: The opposite of additive noise. Not generally caused by a lack of sound to be converted to packets, but rather the result of packet loss in the transmission.
In addition to additive or subtractive noise on a VoIP call, the seventh layer of the OSI model also has the potential for over-modulation, which flattens out the inflection in the speaker’s voice, making him or her sound robotic.
The world of VoIP actually has two categories of noise — the undesired and the desired:
* Undesired noise: The side effect of poor transmission, packets that are lost or arrive out of sequence, modulation, and electrical issues on the line. These aspects of VoIP transmission reduce call quality.
* Desired noise: Called comfort noise — the soft static or white noise you hear during a call during those moments when nobody is speaking. The VoIP phone or phone system at your building generates this noise. VoIP conserves bandwidth by transmitting audio only when someone is speaking. So, only one RTP stream needs to send any audio during that time. But hearing dead silence on a call makes most people think they’ve been disconnected. Your phone or phone system keeps you happy by injecting comfort noise so that you know the line is still active.
Introducing VoIP calls for testing
VoIP is a completely different creature than what normally lives on your LAN. The fat data packets sprinting though your routers are about ten times the size of your average VoIP packet. To put it in perspective, your network switches and routers have to process, on average, ten VoIP packets for every one data packet to push the same volume of information.
This comparison may seem like a bit of fun with numbers, but it has a very real impact on your LAN. The quantity of packets flowing through your LAN is very important, more so than the size of those packets. Routers, switches, firewalls, and all other LAN devices are rated by the Packets Per Second (PPS) that they can transmit. If you’re already pushing your routers’ PPS limits, adding VoIP to the LAN can quickly push it beyond its capabilities.
One of the most daunting tasks of a VoIP deployment involves trying to understand the impact that VoIP traffic will have on your network before you even buy your first VoIP phone or device. You must assess your network and reinforce your LAN before you deploy VoIP. Trying to patch all the holes in your LAN after you flood it with VoIP takes a lot more effort (and creates a lot more anxiety).
So, you must calculate the impact of VoIP on a network before you have any VoIP devices installed. How do you do that? Any algorithm or hypothetical calculations that you create would be little more than guessing. The exact
traffic footprint of your LAN will be unique to your company. The specific quantity of data and voice packets flowing through your LAN will vary by day, week, hour, minute, and second because of variables such as
Daily downloads of data for remote tape backups Peak phone usage times for incoming service calls Peak outbound phone usage for pro-active sales calls Peak data processing times because of
• Receiving orders
• Processing orders
• Processing invoices
• Job cycles for graphics or database work
• Employees downloading videos
Any of these events have a temporary impact on the overall congestion level of your LAN. The only way to effectively identify the impact of VoIP on your LAN is to inject live VoIP calls into it. Fortunately, you can find VoIP Lifecycle Management (VLM) software packages that run test VoIP calls through your LAN.
My favorite VoIP Lifecycle Management software is Packet Island, and I cover it in topic 9. If you want to do a quick test from your LAN, go to www.test yourvoip.com, log in, and get a quick check of the quality of a VoIP call from your LAN to one of a variety of destinations.
However you plan to execute these simulated VoIP calls from your LAN, run your test in a manner that most closely simulates your actual calling pattern. Keep in mind
The quantity of calls you expect to send at any one time
The average duration of calls
Your peak calling time during the day
Placing one call at 5 p.m. on Friday to check the impact of VoIP on your LAN isn’t a realistic test. If you have 20 phone lines and half of them are filled at your peak hours of 10 a.m. and 3 p.m., then set up a simulation for those times that will send ten calls at the same time.
Ideally, you’d set up a constant test of ten VoIP calls from the moment your business opens to the moment it closes. The only thing better than a full day’s worth of test results is test results over the course of a week — or a few weeks.
Your data network is working harder on some days than on others. If you run billing every Monday, be sure to test on a Monday. A VoIP simulation on a Wednesday might show that your LAN is ready for deployment. In spite of the fact that’s good news to your CFO, it doesn’t reflect reality. Always test your LAN on peak data days to discover the congestion on your network. Don’t test when you know your LAN doesn’t have much activity just to avoid having to deal with the congestion.
