una colección de buenos artículos de Voz IP

1. 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

2. 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.

3. 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 prioritization
Tom 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 Nolle
CIMI 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

4. 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.

5. 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 VoIP
Robbie 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
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

6. 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.
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
MPLS and QoS series
1. MPLS: Interoperability of
customer QoS with provider
QoS
2. MPLS: Experimental bits
and QoS
3. MPLS QoS models

7. 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)
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.

8. 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 fundamentals
A 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.
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
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

9. 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.
Ethernet
Trailer
Digitized
Voice
RTP
Header
UDP
Header
IP
Header
Ethernet
Header
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

10. 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 detection
Calculating 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.

11. 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

12. (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 packet
Compressed RTP (cRTP) assumes 4-octets RTP/UDP/IP overhead per packet
Ethernet overhead adds 18-octets per packet
PPP/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.

13. 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.

14. 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 Kbps
5.3 Kbps
4.0
3.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 fundamentals
VoIP 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

15. 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.

16. 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:
• 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.
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

17. 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.

18. 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
Figure 2. Utilization averages over one month
More on VoIP performance
testing
Stop VoIP anomalies before
they impact performance
More VoIP tips

19. 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?

20. 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

21. 7.-Session border control: The good, the bad,
the ugly
Mike 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,

22. 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.

23. 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
Inicio
9.-Wireless voice over IP: What 802.11ac will
do for VoIP
Brad Casey, Network Security
Feature VoIP PSTN
Connectivity type Internet connectivity Dedicated telephone lines
Required bandwidth Requires about 10 Kbps in each
direction
Typically 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.

24. 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.

25. 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