Artículos de VoIP Techtarget.com:

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

2.- Why is VoIP quality of service so challenging during implementations?

3.- IP telephony QoS: VoIP traffic management and prioritization

4.-Carrier MPLS support for VoIP

5.-VoIP bandwidth fundamentals

6.-VoIP performance testing fundamentals

7.-Session border control: The good, the bad, the ugly

8.- PSTN vs. VoIP: What's best for your business?

9.-Wireless voice over IP: What 802.11ac will do for VoIP

1.- How does VoIP performance differ over LAN, WAN and other networks?Matt Brunk, UC Strategies Expert 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.

Inicio

2.- Why is VoIP quality of service so challenging during implementations?Jon Arnold, IP Telephony Expert

Why is quality of service (QoS) so challenging in Voice over IP (VoIP) implementations? Are there different steps that can be taken to ensure there won't be voice distortion and other issues?

The main reason for this challenge is that most forms of VoIP service, especially for residential subscribers, are provided over the public Internet. This is a primary reason why VoIP is cheaper than legacy telephony, which also happens to be the primary reason people make the switch. Everything comes with a price, and in this case, the trade-off is quality and reliability. When traversing the public Internet, VoIP is provided on a "best efforts" basis, meaning that it performs very well when there is sufficient bandwidth, but that can be highly variable.

QoS refers to a metric that reflects the performance of VoIPbased on a variety of factors that apply to voice traffic running over an IP network. Maintaining a high level of VoIP quality of service is one of the best ways to demonstrate that VoIP can perform at a carrier-grade level. When VoIP runs over a private IP network, QoS is high, mainly because the carrier has end-to-end control over the connection and can prioritize voice over other forms of data traffic.

Most VoIP traffic, however, runs over the public Internet, where operators do not have that ability. This means that VoIP must share bandwidth with everything else. And even though it only consumes a nominal amount of broadband, its performance is highly sensitive to even nominal variances caused by bandwidth-intensive applications such as streaming video or online gaming. VoIP providers, therefore, are at the mercy of how their subscribers are using the full gamut of online applications, and invariably there will be poor quality VoIP sessions when overall network activity peaks.

Inicio

3.- IP telephony QoS: VoIP traffic management and prioritizationTom Nolle

Most IP telephony Quality of Service (QoS) problems are created by congestion, which occurs when network load exceeds network capacity for a period of time. The most effective method for managing congestion is to augment capacity in some way, as I discussed in my previous article, IP telephony QoS: Capacity planning and management.

Is your network experiencing voice quality problems because of congestion? If not, there may be fundamental design issues to address.

Tom NolleCIMI Corp.

Sometimes, however, congestion isn't the problem with IP telephony QoS, and sometimes it's not practical to add capacity to alleviate IP telephony QoS issues. In these situations, VoIP traffic management and prioritization can help.

Achieving IP telephony QoS: Setting goals for VoIP traffic management

The first step in independent VoIP traffic management is to set the goals of the process. Is your network experiencing voice quality problems because of congestion? If not, then there may be fundamental design issues to address.

One indication that network congestion isn't the problem is unacceptable network delay, even when utilization on all of the links remains within design levels. In these cases, you will often see a relatively large delay without corresponding packet loss.

If that's the case, you may be experiencing a handling delay problem.

Identifying and prioritizing VoIP traffic can ease congestion

If you have IP telephony QoS issues created by congestion and can't attack the source by adding capacity or limiting traffic from competing applications, you may need to prioritize your VoIP traffic. Prioritization will let the traffic move to the head of the queue at any point where traffic is backed up, so the key to prioritization is to know where the backups are happening. Look at the interface statistics presented by your management system. Prioritization will help in spots where you find deep queues on an output interface.

To prioritize VoIP traffic to alleviate congestion delay, you'll need one of two things:

A way to make your current devices understand traffic priority (e.g., through packet inspection,

looking for VoIP packets), or

A device designed to perform application-based optimization of VoIP traffic through priority

handling.In either case, you'll have to identify your VoIP traffic in some way and then apply handling rules for prioritizing that traffic. You'll need to do this wherever the VoIP traffic management system report indicates that your traffic is encountering deep queues.

Because most networks use faster trunks than ports, you'll probably find your congestion problem close to the network edge, where interfaces are slower. If that's the case, it may not be necessary to tinker with priority handling and routing deeper in the network.

Understanding delay and routing to improve IP telephony

Sometimes VoIP traffic is degraded -- and VoIP traffic management complicated -- not by congestion but simply because there are too many devices between the source and destination. Handling delay is the result of the normal process of switching a packet through a switch or router. The packet must be read from the input port, examined to make a forwarding decision, and then written to the output port. Serialization delay -- the time it takes to read or write a packet -- is dependent on packet size and link speed.

Routing delay is the time it takes to make the forwarding decision. This can sometimes be overlapped with the input read if the switch/router can examine the header only when it's been completely read. Faster ports and trunks will reduce serialization delay, so that may be a good option for the local area network (LAN) portion of any data path. Having fewer devices along a path reduces delay accumulation, so more direct routes may be a good strategy where route complexity is the problem.

In IP networks, there are various ways of providing Class of Service (CoS)-based routing, depending on how your VoIP traffic is identified. It may be necessary to tag the traffic near the network edge to make efficient use of the techniques. Remember: Too many routing table entries defining special handling for a given type of traffic will increase delay for all traffic. Try to use a tagging technique for VoIP traffic management that lets you manage internal traffic routes without adding discrete entries for each VoIP traffic flow.

In Ethernet networks, spanning tree limitations prevent the creation of alternate routes, but there are data center enhancements available for Ethernet that may allow you to create alternate paths that your VoIP traffic can then be directed to take. You'll need to check with your switch vendors to ensure that they all support these enhancements. If they do, you may be able to establish a separate virtual LAN (VLAN) for VoIP traffic management and create more direct routes to reduce latency.

With any form of prioritization and route optimization, you'll need to be especially cautious if your VoIP traffic is part of a unified communications and collaboration (UCC) application. Some collaborative applications, like whiteboard, are also delay-sensitive, and you may find that prioritizing only VoIP will create a disconnect between voice and whiteboard activity. If video is used in collaboration, the voice channel will most likely ride with the video, meaning that you'll have to prioritize the whole flow. Where networks are already congested, doing so may make other applications prohibitively slow when video is used.

VoIP traffic management and prioritization can improve IP telephony QoS but can also increase the overall complexity of the network, raising operations and support costs. It's important to assess the total impact of any proposed VoIP traffic management and prioritization solutions before implementing any and to try lowest-cost strategies first to ensure that overall return on investment meets company goals.

Inicio

4.-Carrier MPLS support for VoIPRobbie Harrell

Meeting quality of service guarantees that ensure reliable voice transmissions can be the biggest challenge of deploying VoIP. Implementing Multi-Protocol Label Switching (MPLS) can help enterprises rise to that challenge because the protocol offers network engineers a great deal of flexibility and the ability to send voice and data traffic around link failures, congestion and bottlenecks.

This article discusses how today's network transport carriers provide support for VoIP with their MPLS offerings. It will also explain the best way to leverage a carrier's MPLS services to support the deployment of real-time services.

MPLS and VoIP play well together

MPLS is useful as an enabler for VoIP because it providesAsynchronous Transfer Mode (ATM)-like capabilities with an IP network. Unlike the expensive ATM links that would be required to support VoIP, MPLS provides guaranteed services utilizing IP quality of service on the carrier's backbone. This service and the ability to converge VoIP onto the data network present a tremendous opportunity to reduce operational costs and consolidate infrastructures.

Similarly, VoIP is a major driver for migrating to an MPLS-based environment. In most cases, MPLS is no more cost-effective than other WAN transport options, but it is a more effective solution for transporting VoIP. MPLS may create efficiency regarding the cost of managing a WAN backbone, but in reality, the cost of an

MPLS solution is generally more when the cost of supporting real-time traffic is added to the bill.

More on MPLS

Multiprotocol Label Switching (MPLS) is a standards-approved technology for speeding up network traffic flow and making it easier to manage. In addition to moving traffic faster overall, MPLS is flexible and cost efficient, and allows for network segmentation.

Get up-to-speed on MPLS with our MPLS Crash Course

Real-time services are application services that are susceptible to delay, packet loss and jitter. VoIP and video over IP are considered real-time applications. While other applications such as SAP are vulnerable to delay, VoIP and video over IP (with corresponding voice) are the real focus, because if you cannot deliver these applications with a high degree of confidence that the packets will not be dropped, experience delay or jitter, then you cannot deploy these application services.

How it works

MPLS allows carriers to deliver WAN transport services over an IP backbone using MPLS technology to create virtual circuits, much in the same way that carriers traditionally built ATM and frame circuits over cell-switched backbones. However, there is a major difference; the IP backbones over which the MPLS services are

provisioned support Class of Service (CoS) that provides a predictable Quality of Service (QoS) over the IP backbone. This is where support for VoIP is enabled on the carrier's backbone.

Most carriers offer multiple classes of service and some try to differentiate themselves based on the numbers of classes. However, all the carriers offer a class of service that is dedicated to VoIP traffic. This class of service provides the ability for the carrier to service all VoIP traffic prior to servicing any other traffic. The VoIP traffic gets priority over other traffic types (such as email, FTP or batch processing).

Important considerations for VoIP traffic There are several significant factors that must be understood regarding how to provision and deploy VoIP from a customer perspective. First, there are different types of VoIP traffic. VoIP has two distinct traffic types:

call signaling traffic (used to set up the VoIP call between two endpoints)

call bearer traffic (the VoIP packets that make up the actual conversation).

If you think about a WAN link to an MPLS cloud, there is only a certain amount of bandwidth available. With an MPLS offering, it is up to the customer to determine what traffic should go in what CoS bucket and how much bandwidth to allocate to the bucket. The carriers provide rules of thumb, but these generally relate to what traffic to put in what bucket, not how much.

In most cases, CoS 1 is the class into which customers will want to put the VoIP bearer traffic. CoS 2 is good for video and CoS 3 is a good fit for signaling traffic. The carriers usually offer profiles for their CoS offerings with various percentages of bandwidth allocated to each of the classes.

For example, Profile 1 may be as follows:CoS 1 - 60% of link bw (VoIP traffic) CoS 2 - 20% of link bw (critical traffic -- SAP eCRM) CoS 3 - 5% of link bw (signaling traffic for VoIP/video) CoS 4 - 10% of link bw (email, FTP) CoS 5 - 5 % of link bw (all other traffic)

MPLS and QoS series

1. MPLS: Interoperability of customer QoS with provider QoS

2. MPLS: Experimental bits and QoS

3. MPLS QoS models

Or it could be provisioned like this: CoS 1 - 40% of link bw (VoIP traffic) CoS 2 - 30% of link bw (critical traffic -- SAP eCRM) CoS 3 - 5% of link bw (signaling traffic for VoIP/video) CoS 4 - 15% of link bw (email, FTP) CoS 5 - 10% of link bw (all other traffic)

Some carriers offer many, many profiles from which customers can choose. It all depends on their mix of traffic. However, VoIP goes in CoS 1 as it must be delivered before any other traffic.

This is important for VoIP because VoIP represents additional traffic being added to the data link layer. If you utilize a T1 between two sites for data traffic, VoIP traffic will increase the bandwidth significantly, especially since you must reserve bandwidth for VoIP. The carriers offer the profiles; you, as the customer, have to choose which profile maps to the actual traffic flowing over the links. Making this decision can be challenging if you have not yet deployed VoIP, but in reality, the rightsizing of the data links and the choosing of the CoS profiles should be done prior to deploying the MPLS network. This requires a voice traffic study that considers peak call volumes between sites and then the translation of the traditional phone call bandwidth into VoIP bandwidth.

Traditional time division multiplexer voice calls without compression utilize 64Kbs. These can be encapsulated in IP with different codecs. The choice of codec will determine the amount of bandwidth utilized by the VoIP call (plus any L2 or L3 encapsulations). The amount of VoIP bandwidth needed for the peak busy hour is the amount that is needed to be reserved in CoS1. The carrier should have a profile that maps closely to this.

Be warned that carriers support what you buy. Many MPLS carriers use a mechanism called policing on the ingress port of the MPLS router. The carrier will monitor (police) the link and if the reserved bandwidth for CoS 1 is exceeded, the carrier will drop the packets. This will disrupt VoIP traffic. This may seem like a bad thing, but in reality it is a good way of alerting customers when they have oversubscribed their CoS profile and need to increase capacity. This is very critical when sending VoIP over a data network.MPLS has come a long way and has in truth accelerated the adoption of VoIP. Both VoIP and MPLS took a long time to mature with VoIP maturing sooner. Now that the MPLS offerings are viable and can support VoIP, many organizations are utilizing MPLS transport as an enabler for a true IP-convergent environment.

Inicio

5.-VoIP bandwidth fundamentalsA Bandwidth requirements for Voice over IP can be a tricky beast to tame until you look at the method and factors involved. This guide investigates what bandwidth means for VoIP, how to calculate bandwidth consumption for a VoIP network and how bandwidth can be saved by using voice compression.

More on this topic

Migrating to MPLS 

What is the relevance of MPLS in regards to QoS for e-commerce?

Interconnecting MPLS clouds 

More VoIP tips

Table of contents

1. What about bandwidth for VoIP?

An introduction to bandwidth issues for Voice over IP and its different components.

2. Calculating bandwidth consumption for VoIP

This section discusses how bandwidth can be calculated for VoIP transmissions and what

strategies work best for the majority of situations.

3. How can voice compression save bandwidth?

Using voice compression can be one of the best strategies when trying to save bandwidth. This

section discusses how these 'savings' can be achieved.

What about bandwidth for VoIP?

Voice over IP (VoIP) is the descriptor for the technology used to carry digitized voice over an IP data network. VoIP requires two classes of protocols: a signaling protocol such as SIP, H.323 or MGCP that is used to set up, disconnect and control the calls and telephony features; and a protocol to carry speech packets. The Real-Time Transport Protocol (RTP) carries speech transmission. RTP is an IETF standard introduced in 1995 when H.323 was standardized. RTP will work with any signaling protocol. It is the commonly used protocol among IP PBX vendors.

An IP phone or softphone generates a voice packet every 10, 20, 30 or 40ms, depending on the vendor's implementation. The 10 to 40ms of digitized speech can be uncompressed, compressed and even encrypted. This does not matter to the RTP protocol. As you have already figured out, it takes many packets to carry one word.

The shorter the packet, the shorter the delay

End-to-end (phone-to-phone) delay needs to be limited. The shorter the packet creation delay, the more network delay the VoIP call can tolerate. Shorter packets cause less of a problem if the packet is lost. Short packets require more bandwidth, however, because of increased packet overhead (this is discussed below). Longer packets that contain more speech bytes reduce the bandwidth requirements but produce a longer construction delay and are harder to fix if lost. Many vendors have chosen 20 or 30ms size packets.

RTP packet format

The RTP header field contains the digitized speech sample (20 or 30ms of a word) time stamp and sequence number and identifies the content of each voice packet. The content descriptor defines the compression technique (if there is one) used in the packet. The RTP packet format for VoIP over Ethernet is shown below.

EthernetTrailer

DigitizedVoice

RTPHeader

UDPHeader

IPHeader

EthernetHeader

RTP can be carried on frame relay, ATM, PPP and other networks with only the far right header and left trailer varying by protocol. The digitized voice field, RTP, UDP and IP headers remain the same.

Each of these packets will contain part of a digitized spoken word. The packet rate is 50 packets per second for 20ms and 33.3 packets per second for 30ms voice samples.The voice packets are transmitted at these fixed rates. The digitized voice field can contain as few as 10 bytes of compressed voice or as many as 320 bytes of uncompressed voice.

The UDP header carries the sending and receiving port numbers for the call. The IP header carries the sending and receiving IP addresses for the call plus other control information. The Ethernet header carries the LAN MAC addresses of the sending and receiving devices. The Ethernet trailer is used for error detection purposes. The Ethernet header is replaced with a frame relay, ATM or PPP header and trailer when the packet enters a WAN.

'Shipping and handling'

In reality, there is no Voice over IP. It is really voice over RTP, over UDP, over IP and usually over Ethernet. The headers and trailers are required fields for the networks to carry the packets. The header and trailer overhead can be called the shipping and handling cost.

The RTP plus UDP plus IP headers will add on 40 bytes. The Ethernet header and trailer account for another 18 bytes of overhead, for a total of at least 58 bytes of overhead before there are any voice bytes in the packet. These headers, plus the Ethernet header, produce the overhead for shipping the packets. This overhead can range from 20% to 80% of the bandwidth consumed over the LAN and WAN. Many implementations of RTP have no encryption, or the vendor has provided its own encryption facilities. An IP PBX vendor may offer a standardized secure version of RTP (SRTP).

Shorter packets have higher overhead. There are 54 bytes of overhead carrying the voice bytes. As the size of the voice field gets larger with longer packets, the percentage of overhead decreases -- therefore the needed bandwidth decreases. In other words, bigger packets are more efficient than smaller packets.

Header compression

Cisco has created a header compression technique that is now the standard called RTP header compression. This technique actually compresses the RTP, UDP and IP headers and significantly reduces the RTP, UDP and IP overhead from 40 bytes to between 4 and 6 bytes. The bandwidth consumption for compressed voice packets can be reduced by nearly 60%. This technique has less value for large uncompressed voice packets. The header compression technique is not recommended for the LAN implementations because there is typically more than enough bandwidth for voice calls. The header compression technique should be considered for the WAN implementations, where bandwidth is limited and much more expensive.

Calculating bandwidth consumption for VoIP

The bandwidth needed for VoIP transmission will depend on a few factors: the compression technology, packet overhead, network protocol used and whether silence suppression is used. This tip investigates the first three considerations. Silence suppression will be covered in a later tip.

There are two primary strategies for improving IP network performance for voice: Allocate more VoIP bandwidth (reduce utilization) or implement QoS.

How much bandwidth to allocate depends on:

Packet size for voice (10 to 320 bytes of digital voice)

CODEC and compression technique (G.711, G.729, G.723.1, G.722, proprietary)

Header compression (RTP + UDP + IP), which is optional

Layer 2 protocols, such as point-to-point protocol (PPP), Frame Relay and Ethernet

Silence suppression/voice activity detectionCalculating the bandwidth for a VoIP call is not difficult once you know the method and the factors to include. The chart below, "Calculating one-way voice bandwidth," demonstrates the overhead calculation for 20 and 40 byte compressed voice (G.729) being transmitted over a Frame Relay WAN connection. Twenty bytes of G.729 compressed voice is equal to 20 ms of a word. Forty bytes of G.729 compressed voice is equal to 40 ms of a word.

The results of this method of calculation are contained in the next table, "Packet voice transmission requirements." The table demonstrates these points:

Bandwidth requirements reduce with compression, G.711 vs. G.729.

Bandwidth requirements reduce when longer packets are used, thereby reducing overhead.

Even though the voice compression is an 8 to 1 ratio, the bandwidth reduction is about 3 or 4

to 1. The overhead negates some of the voice compression bandwidth savings.

Compressing the RTP, UDP and IP headers (cRTP) is most valuable when the packet also carries

compressed voice.

Packet voice transmission requirements(Bits per second per voice channel)

Codec Voice bit rate

Sample time

Voice payload

Packets per second

Ethernet PPP or Frame Relay

RTP cRTP

G.711 64 Kbps 20 msec 160 bytes 50 87.2 Kbps

82.4 Kbps

68.0 Kbps

G.711 64 Kbps 30 msec 240 bytes 33.3 79.4 Kbps

76.2 Kbps

66.6 Kbps

G.711 64 Kbps 40 msec 320 bytes 25 75.6 Kbps

73.2 Kbps

66.0 Kbps

G.729A8 Kbps 20 msec 20 bytes 50 31.2 Kbps

26.4 Kbps

12.0 Kbps

G.729A8 Kbps 30 msec 30 bytes 33.3 23.4 Kbps

20.2 Kbps

10.7 Kbps

G.729A8 Kbps 40 msec 40 bytes 25 19.6 Kbps

17.2 Kbps

10.0 Kbps

Note: RTP assumes 40-octets RTP/UDP/IP overhead per packetCompressed RTP (cRTP) assumes 4-octets RTP/UDP/IP overhead per packet

Ethernet overhead adds 18-octets per packetPPP/Frame Relay overhead adds 6-octets per packet

This table provided courtesy of Michael Finneran.

The varying designs of packet size, voice compression choice and header compression make it difficult to determine the bandwidth to calculate for a continuous speech voice call. The IP PBX or IP phone vendor should be able to provide tables like the one above for their products. Many vendors have selected 30 ms for the payload size of their VoIP implementations. A good rule of thumb is to reserve 24 Kbps of IP

network bandwidth per call for 8 Kbps (G.729-like) compressed voice. If G.711 is used, then reserve 80 Kbps of bandwidth.

If silence suppression/voice activity detection is used, the bandwidth consumption may drop 50% -- to 8 Kbps total per VoIP call. But the assumption that everyone will alternate between voice and silence without conflicting with each other is not always realistic. Silence suppression will be discussed in a later tip.

Most enterprise designers do not perform these calculations. The vendor provides the necessary information. The designer does have some freedom, such as selecting the compression technique for voice payloads and headers, and may be able to vary the packet size.

How can voice compression save bandwidth?

The Public Switched Telephone Network (PSTN) started with the transmission of analog speech. This worked well for decades until the areas under city streets became saturated with copper cables, one copper pair per call. Starting in the 1950s, AT&T Bell Labs developed a technique to carry more voice calls over copper wire. They developed digitized voice technology through which 24 digital calls can be carried on two pairs of copper wire, thereby increasing the carrying capacity of the cables twelvefold. The voice is digitized into streams of 64,000 bps per call. The technology is called a T1 circuit and the bandwidth for the 24 calls is 1.544 Mbps. This worked well for domestic connections. The T1 technology then became the mechanism for long-distance domestic transmission.

Most of the early voice compression technologies were designed for undersea cables, where bandwidth was limited and expensive. Voice compression technologies were created to reduce this bandwidth requirement. Voice compression is also used for digital cell calls, operating at about 8 Kbps instead of 64 Kbps. So voice compression is not new.

As the PBX market has moved into an IP-based environment, voice compression has become attractive for WAN transmission. Voice compression can be used on a LAN, but since LANs have so much available bandwidth, it is not commonly applied to the LAN.

The quality of a PSTN voice call provides enough analog bandwidth to understand the speaker in any language. It is also enough bandwidth for speaker recognition. The analog bandwidth delivered by the PSTN is about 3.4 KHz. This is considered toll quality. Voice compression can reduce the speech quality and may affect speaker recognition, so there is a limit to how much bandwidth reduction is possible before callers complain about voice quality.

The CODEC (COder/DECoder) is the component in an IP phone that digitizes the voice and converts it back into an analog stream of speech. The CODEC is the analog-to-digital-to-analog converter. The CODEC may also perform the voice compression and decompression.

There are several voice digitization standards and some proprietary techniques in use for VoIP transmission. Most vendors support one or more of the following ITU standards and avoid proprietary solutions:

G.711 is the default standard for IP PBX vendors, as well as for the PSTN. This standard digitizes voice into 64 Kbps. There is no voice compression.

G.729 is supported by many vendors for compressed voice operating at 8 Kbps, 8 to 1 compression. With quality just below that of G.711, it is the second most commonly implemented standard.

G.723.1 was once the recommended compression standard. It operates at 6.3 Kbps and 5.3 Kbps. Although this standard further reduces bandwidth consumption, voice is noticeably poorer than with G.729, so it is not very popular for VoIP.

G.722 operates at 64 Kbps, but offers high-fidelity speech. Whereas the three previously described standards deliver an analog sound range of 3.4 kHz, G.722 delivers 7 kHz. This version of digitized speech has been announced by several vendors and will become common in the future.

It is important to note that all of the voice digitization transmission speeds are for voice only. The actual transmission speed required must include the packet protocol overhead.

The quality of a voice call is defined by the Mean Opinion Score (MOS). A score of 4.4 to 4.5 out of a possible 5.0 is considered to be toll quality. Voice compression will affect the MOS. An MOS below 4.0 will usually produce complaints from the callers. Cell phone calls average about 3.8 to 4.0 for the MOS. The following table presents the voice MOS for different standard CODECs:

Standard Speed MOSSampling delay per phone

G.711 64 Kbps 4.4 0.75 ms

G.729 8 Kbps 4.2 10 ms

G.723.1 6.3 Kbps5.3 Kbps

4.03.5

30 ms

This table illustrates two points. First, as the voice is compressed, the voice quality (MOS) decreases. The MOS in the table does not include network impairments such as jitter and packet loss. These impairments will further reduce the voice quality. The VoIP network designer should choose a compression technique with a higher MOS so the network impairments will not reduce the voice quality to an unacceptable level.

Second, voice compression also adds delay to the end-to-end call. The table shows the sampling delay for one phone. This delay is doubled for the two phones of a call. This end-to-end delay needs to be limited. As compression increases, the delay experienced in the IP network needs to decrease, which increases the cost of transmission over the WAN, but not the LAN. The delays shown in the table are the theoretical minimum. The actual delays experienced will probably exceed 30 ms, no matter what compression technology is implemented. This delay will vary by vendor.

The conclusion is that digital voice compression is worth pursuing for VoIP transmission on a WAN, but it comes with some costs in voice quality reduction and increased end-to-end delay.

Inicio

6.-VoIP performance testing fundamentalsVoIP network performance testing can mean the difference between a VoIP system working at a high level QoS and a weak system that runs so poorly customers could take their business elsewhere. This guide discusses why it is important to run regular performance testing and some of the ways it can be done.

Table of contents

1. How can virtual network test beds ensure VoIP performance?

-- Using a virtual network test bed before implementing a VoIP can help guarantee both the

initial VoIP deployment and the long-term health of a VoIP network.

2. What can your manageable electronics tell you before you implement VoIP?

-- Before implementing a VoIP network, it is important to look at all the factors to determine if

the network will run as planned.

3. How can one test VoIP functionality with their existing PBX or Key system?

-- This section discusses useful configurations for testing VoIP functionality on an existing PBX or

Key system.

4. When should a VoIP system be analyzed and with what tools?

-- This section discusses some options for analyzing a VoIP network and what tools can be

helpful in the process.

How can virtual network test beds ensure VoIP performance?Voice over IP (VoIP) technology offers a wide range of benefits -- including reduction of telecom costs,

management of one network instead of two, simplified provisioning of services to remote locations, and the ability to deploy a new generation of converged applications. But no business can afford to have its voice services compromised. Revenue, relationships and reputation all depend on people being able to speak to each other on the phone with five 9's reliability.

Thus, every company pursuing the benefits of VoIP must take steps to ensure that their converged network delivers acceptable call quality and non-stop availability.

A virtual network test bed is particularly useful for taking risk out of both initial VoIP deployment and long-term VoIP ownership. Essentially, such a test bed enables application developers, QA specialists, network managers and other IT staff to observe and analyze the behavior of network applications in a lab environment that accurately emulates conditions on the current and/or planned production network. This emulation should encompass all relevant attributes of the network, including:

Seven best practices for a risk-free VoIP deployment

1. Capture conditions on network to define scenarios 

2. Run VoIP services in a testing lab under real-world scenarios 

3. Analyze call quality 

4. Validate call quality 

5. Repeat to validate quality remedies 

6. Do pre-deployment acceptance testing 

7. Continue applying above best practices

All network links and their impairments, such as: physical distance and associated latency,

bandwidth, jitter, packet loss, CIR, QoS, MPLS classification schemes, etc.,

the number and distribution of end users at each remote location and

application traffic loads.

This kind of test bed is indispensable for modeling the performance of VoIP in the production environment, validating vendor claims, comparing alternative solutions, experimenting with proposed network enhancements, and actually experiencing the call quality that the planned VoIP implementation will deliver.

Following are seven best practices for applying virtual network test bed technology to both initial VoIP deployment and ongoing VoIP management challenges:

1. Capture conditions on the network to define best-case, average-case and worst-case scenarios

Conditions in a test lab won't reflect conditions in the real-world environment if they are not based on empirical input. That's why successful VoIP adopters record conditions on the production network over an extended period of time and then play back those conditions in the lab to define best-, average-, and worst-case scenarios. By assessing VoIP performance under these various scenarios, project teams can readily discover any problems that threaten call quality.

2. Use the virtual network to run VoIP services in the testing lab under those real-world scenarios

Once the network's best-, average-, and worst-case scenarios have been replicated in the test environment, the project team can begin the process of VoIP testing by running voice traffic between every set of endpoints. This can be done by actually connecting phones to the test bed. Call generation tools can also be used to emulate projected call volumes.

3. Analyze call quality with technical metrics

Once VoIP traffic is running in an accurately emulated virtual environment, the team can apply metrics such as mean opinion score (MOS) to pinpoint any specific places or times where voice quality is unacceptable. Typically, these trouble spots will be associated with observable network impairments -- such as delay, jitter and packet loss -- which can then be addressed with appropriate remedies.

4. Validate call quality by listening to live calls

Technical metrics alone can be misleading, since the perception of call quality by actual end users is the ultimate test of VoIP success. So the virtual environment should be used to enable the team to validate firsthand the audio quality on calls between any two points on the network under all projected network conditions. Again, a call generator can be used so that testers can act as the "nth" caller at any location.

5. Repeat as necessary to validate quality remedies

A major advantage of a virtual environment is that various fixes can be tried and tested without disrupting the production network. Testing in the virtual environment should therefore be an iterative process, so that all bugs can be fully addressed and the rollout of VoIP in the production environment can be performed with a very high degree of certainty.

6. Bring in end users for pre-deployment acceptance testing

Since voice quality is ultimately a highly subjective attribute, many VoIP implementation teams have found that it is worthwhile to bring in end users for acceptance testing prior to production rollout. This greatly reduces the chance of the dreaded VoIP mutiny syndrome, where end users balk at call quality despite the best efforts of IT and the fact that call quality meets common industry standards.

7. Continue applying the above best practices over time as part of an established change management process To maintain VoIP quality over time, IT organizations must incorporate the above best practices into their change management practices. This is essential for ensuring that changes in the enterprise environment -- the addition of new locations, the introduction of a new application onto the network, a planned relocation of staff -- will not adversely impact end-to-end VoIP service levels.

It's important to note that while a virtual network test bed will pay for itself by virtue of its support for VoIP and convergence alone, this technology has many other uses that deliver substantial ROI. These uses include the development of more network-friendly applications, better planning of server moves and data center consolidations, and improved support for merger and acquisition (M&A) activity. These significant additional benefits make emulation technology an extremely lucrative investment for IT organizations seeking both to ensure the success of a VoIP project in the near term and to optimize their overall operational excellence in the long term.

What can your manageable electronics tell you before you implement VoIP?

In a recent webcast, we discussed performance management and what to look for when you examine your statistics. One of the worst statistics you can consider as a means to determine your network health is utilization.

There are other statistics that are much more valuable. It is important to look at utilization, but this is only a small piece of health.The problem with utilization is twofold. First, it is nearly impossible to determine when the workstation is actually in use. Even if someone is sitting at his desk, he may be on the phone and not using the network. Also, many users work locally and then save their work to the network when complete. So in utilization you have to know when the network is really in use to determine how much of the bandwidth is being consumed. Look at the following two diagrams, for instance.

Figure 1. Averages over one week

More on VoIP performance testing

Stop VoIP anomalies before they impact performance 

More VoIP tips

Figure 2. Utilization averages over one month

In Figure 1, above, the utilization was measured on the inbound side for a week. Figure 2 shows the same circuit measured over one month. As you can see, the differences in utilization are rather large. When planning for VoIP, you should assume that the peak happens all the time. If not, when processing becomes heavy, you will degrade your voice signal because you have not planned for it.

It is also important to examine buffer space and discards on your active electronics. Switches discard packets as a function. When the buffers get too full, they will drop packets and request a retransmission from the sender. This is not a desirable "feature" for voice. While you can set up VLANs and priority, overloaded gear will not help. In particular, you want to check your discards on any uplink port, and any port that is commonly attached (for instance, where the IP switch may be).

Some errors that you will find in your SNMP data also bear investigation. The most important are bit errors. These may be expressed as InErrors and OutErrors. Not all manageable systems will allow you to drill down further into the error state. Some will allow it, and speed up the troubleshooting process. Anytime you see these errors, the first thing you should do is test your cabling channel that is connected on that port. A brief word about cable testing: Make sure the tester has the latest revision of software and firmware and has been calibrated recently. You also want to be sure that your interfaces and/or patch cords are relatively new. Each has a limited number of mating cycles, and a channel may look bad when in fact it is not.

Next, check your duplex configurations. Duplex mismatches and/or channels that have auto-negotiated to half duplex will further limit your operations. It is important to have full duplex links. A hard setting in

either the switch or at the workstation, or faulty cabling, including channels that exceed the maximum distance, can cause half duplex links.

After you fix your errors, you will want to take another network pulse for 30 days. The reason that I recommend a 30-day window is to allow for such things as month-end processing and other functions that do not happen on a daily basis. A Certified Infrastructure Auditor can assist with all of these steps. For more information on specific errors, see the article Common network errors and causes.

Other SearchVoIP.com members who have already faced real-life testing issues came to our site experts for advice. Read on to find out what suggestions were made to remedy their VoIP performance testing issues.

How can one test VoIP functionality with their existing PBX or Key system?

There are multiple possibilities for testing VoIP functionality with an existing PBX or Key system. How you test depends upon your goal.

If you have two sites linked together with PBX tie lines and you want to try using VoIP so that calls will be routed over your internal network rather than costly tie lines, you can test using a SIP to PSTN gateway (such as the MX25.)

This configuration could look like this:

Existing PBX ← T1 PRI → MX25 ← SIP over WAN network → MX25 ← T1 PRI → Existing PBX

Perhaps you have a single site and you want to keep your existing PBX and connect long distance calls through an Internet telephony service provider that provides superior rates. In this case, you could use a SIP to PSTN gateway and connect in this fashion:

Existing PBX ← T1 PRI → MX25 ← SIP over Internet → ITSP →

Perhaps you are planning on replacing your legacy PBX and putting in an IP PBX (such as theMX250) to test the functionality before cutting over service. In this case, the configuration could look like this:

Existing PBX ← T1 PRI → MX250 ← T1 PRI → PSTN

Using this approach, the existing PBX continues to function as it always has and only dial plan entries are required to route calls between systems. This allows for certain employees to learn the new VoIP system and understand its features before migrating over service.

When should a VoIP system be analyzed and with what tools?

We have recently implemented a VoIP network with separate VLANs and QoS. It all seemed to be working fine when it first went in, but recently, certain people have been complaining about sound breakup whilst talking to customers on the phone. I have also had similar problems, but thought it was due to the amount of diagnostics software that I was running on my PC.

To check, I moved my phone into its own port and the breakup is still there. Any ideas how we can check to make sure that the network is doing alright? Also are there any software utilities that would help us with day to day analyzing?

First and foremost -- I would suggest that you have someone come and test your cabling channels. That will be the least expensive and could be the most worrisome component. Even if the channels tested fine when first installed, they can degrade over time with moves, adds and changes.The other thing you didn't mention was if this occurs only on the intra-office calls or only on outside calls. If it is only on outside calls, you may want to get your carrier to check your circuits.

If these things test out okay, then you will want a RMON tool that can track performance. Check your switch SNMP data for errors. These will also give you a good idea of what the culprit may be. If this is happening to everyone in the building -- start looking for common denominators such as network interface cards in the switch.

Inicio

7.-Session border control: The good, the bad, the uglyMike Jude, Wireless Expert

Prior to enterprise adoption of VoIP, session border control was considered arcane at best. In fact, short of actually engineering interfaces between carrier networks, border control was simply assumed to happen somewhere; after all, who cares how telephone carriers actually route traffic or manage network handoffs? Now, border control is becoming a critical aspect of securing enterprise networks and enabling traffic conditioning so that traffic flows smoothly between enterprise networks, carrier networks and the PSTN. Still, many IT professionals actively avoid session border control, and with good reason. While session management is an important arrow in the IT professional's quiver, it has several issues that may argue against enterprise self-provision in some situations.

The good: Why session border control matters

So why is session border control (SBC) important? Without dwelling terribly long on the subject, SBC is an important way for IT to secure its enterprise network. Services such as VoIP have generally had problems transiting enterprise network border security. On the one hand, as an IP-based data service, securing access through firewalls is desirable; yet firewalls can prevent such activities as call setup and completion or can make such new capabilities as unified communication problematic. Although tunneling through a firewall is certainly possible, doing so can compromise data security. SBC can not only enable VoIP to bypass data firewalls in a way that does not compromise security, it can actually provide more control over voice services generally by aggregating voice traffic. This is all to the good.

The bad: Obstacles of session border control

However, SBC also comes with its problems. For one thing, SBC can be a complex piece of technology: one that demands a certain amount of expertise to set up and maintain. Also, SBC is not a set-and-forget technology; as additions, moves and changes of voice service occur, the SBC must be configured to recognize them. IT must actively manage SBC devices, and this adds to IT overhead.

SBC also comes with some implications for quality of service (QoS). In complex call setup scenarios, traffic packets can be routed to an SBC device and then back again several times for each transmission. Depending on network architecture, this may mean a transit across a rather long call path -- and this

introduces latency into the connection. These problems are certainly solvable, but once again, SBC requires yet another layer of design and oversight when developing network architectures.

The ugly: Who controls the session border?

Yet, the 600-pound gorilla in the room when considering SBC is who controls the session border controller. For the enterprise, it is obviously desirable to be able to secure network connections, yet the carrier -- whose network is being connected to -- is also concerned about such things as QoS, lawful intercept of voice traffic and management of the voice connection.

For these reasons, carriers who offer VoIP connectivity often want to manage the session border controller or specify the controller that the enterprise will use. This is clearly at odds with an enterprise that wants to mask its internal networks from external intrusion. SBC, from the standpoint of the carrier, breaks the end-to-end management of call completion and complicates regulatory obligations such as access to 911 services and call intercept.

Although the battle over control has generally been won in favor of enterprises, many carriers who offer SIP-based connections often make enterprise adoption of SBC technology more of an ordeal than it needs to be. Almost every SBC vendor has developed a rather complete repertoire of support solutions to ensure that carrier concerns are addressed; however, it is still possible to find carriers whose SIP trunking services come with recommended or required SBC vendor solutions.

Complicating this situation is the introduction of cloud-based session control. In this scenario, the SBC functionality is provided through a cloud service. Advantages are that the enterprise can offload a great deal of the management overhead associated with SBC maintenance. The drawback is that VoIP traffic latency can increase dramatically as it transits a much larger network.

Where to go for session border control

Nevertheless, SBC is an important solution for the IT professional. Although there are situations where it is simpler to depend on the carrier to provide session control, there are many where the virtues of enterprise SBC trump local control:

SBCs provide better security control.

SBCs allow for call aggregation.

SBCs give you the ability to use lower-cost SIP trunking.

IT professionals who have found that their responsibilities increase with the adoption of IP-based telephony will want to take a hard look at SBC technology as well as vendors for such technology. Top SBC vendors include (but are not limited to) Acme Packet, Adtran, Audicodes, Avaya, Cisco, Dialogic, Edgewater, Media and others. These solution providers all have excellent professional service organizations that will provide basic tutorials and/or design support. Interested readers are invited to contact this author for vendor contacts if they wish.

Inicio

8.-PSTN vs. VoIP: What's best for your business?Kara Deyermenjian

An increasing number of businesses are opting to replace their Public Switched Telephone Networks (PSTNs) for cheaper VoIP alternatives, but the PSTN vs. VoIP debate is still going strong. Internet telephony was associated with performance issues when VoIP first appeared on the scene and was notorious for dropped calls and poor call quality. Significant strides have been made in the world of VoIP, however, and there are plenty of reasons why making the change could be helpful. Areas where VoIP currently has a leg-up on PSTN include advantages in scalability, cost and special feature availability.

On the other hand, many enterprises want to stick with their plain old telephone service(POTS), (service that runs over the PSTN). The well-known technology has built-in reliability, security and emergency location services. Just because something is plain and old doesn't necessarily mean it's time to rip and replace.

Are you still on the fence about whether or not to make the switch? Our tech-comparison helps you weigh the pros and cons. It's not easy to give up your trusty legacy phone system, but our tech-comparison can help you decide one way or the other.

PSTN vs. VoIP: Feature-by-feature comparison

Feature VoIP PSTNConnectivity type Internet connectivity Dedicated telephone linesRequired bandwidth Requires about 10 Kbps in each

directionTypically requires 64 Kbps in each direction

Pricing Free VoIP-to-VoIP calling (local and international), butcalls to mobile and landline phones have nominal subscription fees of around 1.2 cents to 2.6 cents a minute.

No free calls can be made. Costly international calling. Monthly phone plans usually cost around $25 to $30 per month depending on service provider.

Scalability Upgrades usually require more bandwidth and simple software updates.

Upgrades require purchasing more hardware and dedicated lines, which can be very complex and costly.

Remote extensions This feature is typically standard. This feature typically requires dedicated lines for each extension and is very pricey.

Business continuity/disaster recovery

Service terminates when Internet connectivity (power) is lost. Organizations must have a VoIP disaster recovery plan.

Service usually remains active during power outages because phone jacks do not require electricity. But cordless phones do and would be unusable.

Call waiting Most VoIP options offer free call waiting, such as Google Voice and Skype.

Available at extra cost

Call forwarding Some VoIP options provide free call forwarding (Google Voice), while others offer it for an extra fee or through a subscription (Skype).

Available at extra cost

Call transferring Some VoIP options provide free call transferring (Google Voice), while others do not support call transferring at all (Skype).

Available at extra cost

Emergency calling Depends on the service, but emergency calling is usually not provided by VoIP or isvery limited (Skype). 911 calls are also typically untraceable.

Emergency calling is enabled, and services are traceable to location.

Inicio

9.-Wireless voice over IP: What 802.11ac will do for VoIPBrad Casey, Network Security

With the fast-approaching ratification of the IEEE 802.11ac standard, many applications that were considered throughput hogs in enterprise environments will theoretically cease to consume as many resources. In fact, depending on the processing power of the end device, applications heavily reliant on audio or video functionality will supposedly operate in a manner more reminiscent of Gigabit Ethernet. So right away, YouTube at Starbucks seems like a much more worthwhile proposition than in years past. In terms of unified communications, many of the implications involved with the new Gigabit Wi-Fi standard may not have been completely realized as of yet, but rest assured that voice over IP (VoIP) will find its own niche within this new technology.

Current wireless voice over IP developments

Currently, the average end user has the ability to engage in wireless VoIP calls in residential and/or Wi-Fi hotspot scenarios with profound regularity. Two of the more prominent applications used by common end users are Skype and Windows Live Messenger. While Skype has not yet made their core protocol public, a simple Wireshark capture reveals thatTCP is used for the control signal, while UDP is used for data transfer. This dual utilization of TCP and UDP has gained in popularity in recent years, since it seems to compliment the older SS7 method of using a physical control signal along with a separate -- but also physical -- data signal.

In terms of performance, the real-time applications perform rather well within the IEE 802.11 standard , as long as the node–to-access point (AP) ratio remains low. However, when the network becomes too crowded, items such as Quality of Service (QoS) and overall throughput availability become adversely affected.

With the ratification of the new IEEE 802.11ac standard (Gigabit Wi-Fi) on the immediate horizon, the expectation is that some of the QoS issues found within currently crowded wireless LANs will be alleviated. The new standard supports up to eight spatial streams, as opposed to the four spatial streams supported by its predecessor, 802.11n. The increase in spatial streams will allow for less competition among nodes associated with the same AP, and it will allow wireless administrators to bond spatial streams, thereby allowing bigger pipes across the wireless spectrum. Furthermore, the 802.11ac standard operates within the5GHz frequency band, as opposed to the 2.4 GHz band that its predecessor operates in. This will provide the wireless VoIP end user the opportunity to converse with less concern for overlapping channels than would otherwise be the case under the 802.11n standard.

Wireless voice over IP security issues

Many of the security issues with wireless VoIP have very little to do with the new standard, and therefore 802.11ac will do very little, if anything, in the way of addressing them. As with any other communication conducted wirelessly, the primary vulnerability resides in the fact that everyone within the range of the WLAN has access to the transmission medium: the air. So eavesdropping, man-in-the-middle attacks and other network attacks are only as affective as the wireless encryption protocol is weak. One area where the new 802.11ac standard will most definitely help is in the way of encryption, but not as this encryption pertains to securing the physical signal. The new standard will indirectly help with whatever encryption mechanism is used by the VoIP applications themselves. More specifically, the higher throughput available within 802.11ac will allow for faster processing of the network overhead that invariably comes with any encrypted signal. So, in the case of Skype calls, the end user may experience a considerable jump in performance, since Skype currently encrypts all calls by default. In the case of Windows Live Messenger, the end user may not notice as much of an improvement, since Messenger is unencrypted by default and therefore less consuming of network resources.

Conclusion

Wireless VoIP has gained significant amounts of traction within the small and medium-sized business market, because Cisco and other large companies have developed some fairly robust WVoIP solutions that center on actual wireless phones that associate with APs in the same way that a laptop associates with APs currently. This involves the purchase of a few other network devices, such as the Cisco Unified Communications Manager, so that the processing of wireless packets is handled more quickly and in a more orderly way. For the typical residential user however, the new 802.11ac standard should prove to be a boon to those who engage in WVoIP calls at their favorite Wi-Fi hotspots.

Glosario:

http://searchunifiedcommunications.techtarget.com/definition/VoIP-Glossary

Inicio

Recopilación de fam/ Mayo 2013