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 prioritization4.-Carrier MPLS support for VoIP5.-VoIP bandwidth fundamentals6.-VoIP performance testing fundamentals7.-Session border control: The good, the bad, the ugly8.-PSTN vs. VoIP: Whats best for your business?9.-Wireless voice over IP: What 802.11ac will do for VoIP1.- How does VoIP performance differ overLAN, WAN and other networks?Matt Brunk, UC Strategies ExpertWill VoIP behave differently over different types of networks -- i.e., over a WAN, LAN, VPN, and thelike? 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 thisis 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) andminor keep-alive and will display the date and time of broadcast traffic to your phones. This assumesthat you have on-premises gear, such as an IP-PBX, but if you are using hosted services it depends. Somehosted solutions require your local intercom traffic between stations or extensions on the samepremises to route across the WAN. Other providers have gear on-premises that allows connectivitybetween 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 ofService (QoS), and whether or not youve deployed VLANs.When the voice traffic leaves the LAN, the next hoop to jump through is getting a handle on where thecall goes. MPLS networks are equipped to handle real-time traffic. If your WAN isnt MPLS, then you maybe 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 isimpacted 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 thenrevert to G.711 if the call will not negotiate to the lower bandwidth. This includes GRE tunnels deployedin a mesh network in regards to VPN. But VPN means different things at different times. Its important tonote that, if your VPN is a mesh connection to a data center or hosted provider, you will need toconsider leveraging more bandwidth (assuming you dont have MPLS).For VPN connections serving telecommuters you need to determine that you have the availableresources. This includes some sense of the telecommuters gear and bandwidth. You can still implementQoS for outbound side of traffic headed over broadband. Another good way to leverage voice is to useSIP trunks if your gear (gateway or PBX) is "certified" or has been tested against the providersrequirements. 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 overtheir private network so users can, or at least should, expect a better experience than riding over thepublic Internet. Another example is Verizon FiOS, which performs really well with VoIP. Comcast andother cable TV networks are competing with residential services and TV demands. In addition, I think theVerizon 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 firstchoice to preserve bandwidth for your data applications, unless of course your business model is voice-centric and doesnt have a significant dependency upon data applications.Hosted providers with a soft switch located in California and customers in Virginia dont really have anideal configuration. How many hops do Virginia users go through at different times of day to reachCalifornia? In any public Internet voice solution theres also the issue of time-of-day traffic, such as at 5p.m. EST. If our SIP trunks audio quality is an issue, then its usually because of competing residentialtraffic 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 anongoing challenge does not necessarily mean it must be avoided.Inicio2.- Why is VoIP quality of service sochallenging during implementations?Jon Arnold, IP Telephony ExpertWhy is quality of service (QoS) so challenging in Voice over IP (VoIP) implementations? Are theredifferent steps that can be taken to ensure there wont be voice distortion and other issues?The main reason for this challenge is that most forms of VoIP service, especially for residentialsubscribers, are provided over the public Internet. This is a primary reason why VoIP is cheaperthan legacy telephony, which also happens to be the primary reason people make the switch. Everythingcomes with a price, and in this case, the trade-off is quality and reliability. When traversing the publicInternet, VoIP is provided on a "best efforts" basis, meaning that it performs very well when there issufficient 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 tovoice traffic running over an IP network. Maintaining a high level of VoIP quality of service is one of thebest ways to demonstrate that VoIP can perform at a carrier-grade level. When VoIP runs over a privateIP network, QoS is high, mainly because the carrier has end-to-end control over the connection and canprioritize voice over other forms of data traffic.Most VoIP traffic, however, runs over the public Internet, where operators do not have that ability. Thismeans that VoIP must share bandwidth with everything else. And even though it only consumes anominal amount of broadband, its performance is highly sensitive to even nominal variances caused bybandwidth-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 invariablythere will be poor quality VoIP sessions when overall network activity peaks.Inicio3.- IP telephony QoS: VoIP trafficmanagement and prioritizationTom NolleMost IP telephony Quality of Service (QoS) problems are created by congestion, which occurs whennetwork load exceeds network capacity for a period of time. The most effective method for managingcongestion 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 ofcongestion? If not, there may be fundamental design issues to address.Tom NolleCIMI Corp.Sometimes, however, congestion isnt the problem with IP telephony QoS, and sometimes its notpractical to add capacity to alleviate IP telephony QoS issues. In these situations, VoIP trafficmanagement and prioritization can help.Achieving IP telephony QoS: Setting goals for VoIP traffic managementThe first step in independent VoIP traffic management is to set the goals of the process. Is your networkexperiencing voice quality problems because of congestion? If not, then there may be fundamentaldesign issues to address.One indication that network congestion isnt the problem is unacceptable network delay, even whenutilization on all of the links remains within design levels. In these cases, you will often see a relativelylarge delay without corresponding packet loss.If thats 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 cant attack the source by adding capacityor limiting traffic from competing applications, you may need to prioritize your VoIP traffic. Prioritizationwill let the traffic move to the head of the queue at any point where traffic is backed up, so the key toprioritization is to know where the backups are happening. Look at the interface statistics presented byyour management system. Prioritization will help in spots where you find deep queues on an outputinterface.To prioritize VoIP traffic to alleviate congestion delay, youll 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 priorityhandling.In either case, youll have to identify your VoIP traffic in some way and then apply handling rules forprioritizing that traffic. Youll need to do this wherever the VoIP traffic management system reportindicates that your traffic is encountering deep queues.Because most networks use faster trunks than ports, youll probably find your congestion problem closeto the network edge, where interfaces are slower. If thats the case, it may not be necessary to tinkerwith priority handling and routing deeper in the network.Understanding delay and routing to improve IP telephonySometimes VoIP traffic is degraded -- and VoIP traffic management complicated -- not by congestion butsimply because there are too many devices between the source and destination. Handling delay is theresult of the normal process of switching a packet through a switch or router. The packet must be readfrom the input port, examined to make a forwarding decision, and then written to the outputport. Serialization delay -- the time it takes to read or write a packet -- is dependent on packet size andlink speed.Routing delay is the time it takes to make the forwarding decision. This can sometimes be overlappedwith the input read if the switch/router can examine the header only when its been completely read.Faster ports and trunks will reduce serialization delay, so that may be a good option for the local areanetwork (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 onhow your VoIP traffic is identified. It may be necessary to tag the traffic near the network edge to makeefficient use of the techniques. Remember: Too many routing table entries defining special handling fora given type of traffic will increase delay for all traffic. Try to use a tagging technique for VoIP trafficmanagement that lets you manage internal traffic routes without adding discrete entries for each VoIPtraffic flow.In Ethernet networks, spanning tree limitations prevent the creation of alternate routes, but thereare data center enhancements available for Ethernet that may allow you to create alternate paths thatyour VoIP traffic can then be directed to take. Youll need to check with your switch vendors to ensurethat they all support these enhancements. If they do, you may be able to establish a separate virtualLAN (VLAN) for VoIP traffic management and create more direct routes to reduce latency.
With any form of prioritization and route optimization, youll need to be especially cautious if your VoIPtraffic is part of a unified communications and collaboration (UCC) application. Some collaborativeapplications, like whiteboard, are also delay-sensitive, and you may find that prioritizing only VoIP willcreate a disconnect between voice and whiteboard activity. If video is used in collaboration, the voicechannel will most likely ride with the video, meaning that youll have to prioritize the whole flow. Wherenetworks are already congested, doing so may make other applications prohibitively slow when video isused.VoIP traffic management and prioritization can improve IP telephony QoS but can also increase theoverall complexity of the network, raising operations and support costs. Its important to assess the totalimpact of any proposed VoIP traffic management and prioritization solutions before implementing anyand to try lowest-cost strategies first to ensure that overall return on investment meets company goals.Inicio4.-Carrier MPLS support for VoIPRobbie Harrell•Meeting quality of service guarantees that ensure reliable voice transmissions can be the biggestchallenge of deploying VoIP. Implementing Multi-Protocol Label Switching (MPLS) can help enterprisesrise to that challenge because the protocol offers network engineers a great deal of flexibility and theability to send voice and data traffic around link failures, congestion and bottlenecks.This article discusses how todays network transport carriersprovide support for VoIP with their MPLS offerings. It will alsoexplain the best way to leverage a carriers MPLS services tosupport the deployment of real-time services.MPLS and VoIP play well togetherMPLS is useful as an enabler for VoIP because it providesAsynchronous Transfer Mode (ATM)-likecapabilities 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 carriers backbone. This serviceMore on MPLSMultiprotocol Label Switching(MPLS) is a standards-approved technology forspeeding up network trafficflow and making it easier tomanage. In addition to movingtraffic faster overall, MPLS isflexible and cost efficient, andallows for networksegmentation.Get up-to-speed on MPLSwith our MPLS Crash Course
and the ability to converge VoIP onto the data network present a tremendous opportunity to reduceoperational costs and consolidate infrastructures.Similarly, VoIP is a major driver for migrating to an MPLS-based environment. In most cases, MPLS is nomore cost-effective than other WAN transport options, but it is a more effective solution fortransporting VoIP. MPLS may create efficiency regarding the cost of managing a WAN backbone, but inreality, the cost of an MPLS solution is generally more when the cost of supporting real-time traffic isadded to the bill.Real-time services are application services that are susceptible todelay, packet loss and jitter. VoIP and video over IP areconsidered real-time applications. While other applications suchas SAP are vulnerable to delay, VoIP and video over IP (withcorresponding voice) are the real focus, because if you cannotdeliver these applications with a high degree of confidence thatthe packets will not be dropped, experience delay or jitter, thenyou cannot deploy these application services.How it worksMPLS allows carriers to deliver WAN transport services over an IP backbone using MPLS technology tocreate virtual circuits, much in the same way that carriers traditionally built ATM and frame circuits overcell-switched backbones. However, there is a major difference; the IP backbones over which the MPLSservices are provisioned support Class of Service (CoS) that provides a predictable Quality ofService (QoS) over the IP backbone. This is where support for VoIP is enabled on the carriers backbone.Most carriers offer multiple classes of service and some try to differentiate themselves based on thenumbers of classes. However, all the carriers offer a class of service that is dedicated to VoIP traffic. Thisclass of service provides the ability for the carrier to service all VoIP traffic prior to servicing any othertraffic. 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 understoodregarding how to provision and deploy VoIP from a customer perspective. First, there are different typesof 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 bucketMPLS and QoS series1. MPLS: Interoperability ofcustomer QoS with providerQoS2. MPLS: Experimental bitsand QoS3. MPLS QoS models
and how much bandwidth to allocate to the bucket. The carriers provide rules of thumb, but thesegenerally 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 isgood for video and CoS 3 is a good fit for signaling traffic. The carriers usually offer profiles for their CoSofferings 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 oftraffic. 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. Ifyou 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 thecustomer, have to choose which profile maps to the actual traffic flowing over the links. Making thisdecision can be challenging if you have not yet deployed VoIP, but in reality, the rightsizing of the datalinks and the choosing of the CoS profiles should be done prior to deploying the MPLS network. Thisrequires a voice traffic study that considers peak call volumes between sites and then the translation ofthe traditional phone call bandwidth into VoIP bandwidth.Traditional time division multiplexer voice calls without compression utilize 64Kbs. These can beencapsulated in IP with different codecs. The choice of codec will determine the amount of bandwidthutilized by the VoIP call (plus any L2 or L3 encapsulations). The amount of VoIP bandwidth needed forthe peak busy hour is the amount that is needed to be reserved in CoS1. The carrier should have aprofile that maps closely to this.
Be warned that carriers support what you buy. Many MPLScarriers use a mechanism called policing on the ingress port ofthe MPLS router. The carrier will monitor (police) the link and ifthe reserved bandwidth for CoS 1 is exceeded, the carrier willdrop the packets. This will disrupt VoIP traffic. This may seem likea bad thing, but in reality it is a good way of alerting customerswhen they have oversubscribed their CoS profile and need toincrease capacity. This is very critical when sending VoIP over adata network.MPLS has come a long way and has in truth accelerated the adoption of VoIP. Both VoIP and MPLS tooka long time to mature with VoIP maturing sooner. Now that the MPLS offerings are viable and cansupport VoIP, many organizations are utilizing MPLS transport as an enabler for a true IP-convergentenvironment.Inicio5.-VoIP bandwidth fundamentalsA Bandwidth requirements for Voice over IP can be a tricky beast to tame until you look at the methodand factors involved. This guide investigates what bandwidth means for VoIP, how to calculatebandwidth consumption for a VoIP network and how bandwidth can be saved by using voicecompression.Table of contents1. What about bandwidth for VoIP?An introduction to bandwidth issues for Voice over IP and its different components.2. Calculating bandwidth consumption for VoIPThis section discusses how bandwidth can be calculated for VoIP transmissions and whatstrategies 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. Thissection 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 datanetwork. VoIP requires two classes of protocols: a signaling protocol such as SIP, H.323 or MGCP that isused to set up, disconnect and control the calls and telephony features; and a protocol to carry speechpackets. The Real-Time Transport Protocol (RTP) carries speech transmission. RTP is an IETF standardMore on this topicMigrating to MPLSWhat is the relevance ofMPLS in regards to QoS for e-commerce?Interconnecting MPLS cloudsMore VoIP tips
introduced in 1995 when H.323 was standardized. RTP will work with any signaling protocol. It is thecommonly used protocol among IP PBX vendors.An IP phone or softphone generates a voice packet every 10, 20, 30 or 40ms, depending on the vendorsimplementation. The 10 to 40ms of digitized speech can be uncompressed, compressed and evenencrypted. This does not matter to the RTP protocol. As you have already figured out, it takes manypackets to carry one word.The shorter the packet, the shorter the delayEnd-to-end (phone-to-phone) delay needs to be limited. The shorter the packet creation delay, the morenetwork 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 isdiscussed below). Longer packets that contain more speech bytes reduce the bandwidth requirementsbut produce a longer construction delay and are harder to fix if lost. Many vendors have chosen 20 or30ms size packets.RTP packet formatThe RTP header field contains the digitized speech sample (20 or 30ms of a word) time stamp andsequence number and identifies the content of each voice packet. The content descriptor defines thecompression technique (if there is one) used in the packet. The RTP packet format for VoIP overEthernet is shown below.EthernetTrailerDigitizedVoiceRTPHeaderUDPHeaderIPHeaderEthernetHeaderRTP can be carried on frame relay, ATM, PPP and other networks with only the far right header and lefttrailer 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 persecond for 20ms and 33.3 packets per second for 30ms voice samples.The voice packets are transmittedat these fixed rates. The digitized voice field can contain as few as 10 bytes of compressed voice or asmany as 320 bytes of uncompressed voice.The UDP header carries the sending and receiving port numbers for the call. The IP header carries thesending and receiving IP addresses for the call plus other control information. The Ethernet headercarries the LAN MAC addresses of the sending and receiving devices. The Ethernet trailer is used forerror detection purposes. The Ethernet header is replaced with a frame relay, ATM or PPP header andtrailer when the packet enters a WAN.Shipping and handlingIn reality, there is no Voice over IP. It is really voice over RTP, over UDP, over IP and usually overEthernet. The headers and trailers are required fields for the networks to carry the packets. The headerand 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 foranother 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 thepackets. 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 encryptionfacilities. 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 thesize of the voice field gets larger with longer packets, the percentage of overhead decreases -- thereforethe needed bandwidth decreases. In other words, bigger packets are more efficient than smallerpackets.Header compressionCisco has created a header compression technique that is now the standard called RTP headercompression. This technique actually compresses the RTP, UDP and IP headers and significantly reducesthe RTP, UDP and IP overhead from 40 bytes to between 4 and 6 bytes. The bandwidth consumption forcompressed voice packets can be reduced by nearly 60%. This technique has less value for largeuncompressed voice packets. The header compression technique is not recommended for the LANimplementations because there is typically more than enough bandwidth for voice calls. The headercompression technique should be considered for the WAN implementations, where bandwidth is limitedand much more expensive.Calculating bandwidth consumption for VoIPThe 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 investigatesthe 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 VoIPbandwidth (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 toinclude. The chart below, "Calculating one-way voice bandwidth," demonstrates the overheadcalculation for 20 and 40 byte compressed voice (G.729) being transmitted over a Frame Relay WANconnection. Twenty bytes of G.729 compressed voice is equal to 20 ms of a word. Forty bytes of G.729compressed voice is equal to 40 ms of a word.
The results of this method of calculation are contained in the next table, "Packet voice transmissionrequirements." 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 4to 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 carriescompressed voice.Packet voice transmission requirements
(Bits per second per voice channel)Codec Voice bitrateSampletimeVoicepayloadPackets persecondEthernet PPP or FrameRelayRTP cRTPG.711 64 Kbps 20 msec 160 bytes 50 87.2Kbps82.4Kbps68.0KbpsG.711 64 Kbps 30 msec 240 bytes 33.3 79.4Kbps76.2Kbps66.6KbpsG.711 64 Kbps 40 msec 320 bytes 25 75.6Kbps73.2Kbps66.0KbpsG.729A8 Kbps 20 msec 20 bytes 50 31.2Kbps26.4Kbps12.0KbpsG.729A8 Kbps 30 msec 30 bytes 33.3 23.4Kbps20.2Kbps10.7KbpsG.729A8 Kbps 40 msec 40 bytes 25 19.6Kbps17.2Kbps10.0KbpsNote: RTP assumes 40-octets RTP/UDP/IP overhead per packetCompressed RTP (cRTP) assumes 4-octets RTP/UDP/IP overhead per packetEthernet overhead adds 18-octets per packetPPP/Frame Relay overhead adds 6-octets per packetThis table provided courtesy of Michael Finneran.The varying designs of packet size, voice compression choice and header compression make it difficult todetermine the bandwidth to calculate for a continuous speech voice call. The IP PBX or IP phone vendorshould be able to provide tables like the one above for their products. Many vendors have selected 30ms for the payload size of their VoIP implementations. A good rule of thumb is to reserve 24 Kbps of IPnetwork bandwidth per call for 8 Kbps (G.729-like) compressed voice. If G.711 is used, then reserve 80Kbps of bandwidth.If silence suppression/voice activity detection is used, the bandwidth consumption may drop 50% -- to 8Kbps total per VoIP call. But the assumption that everyone will alternate between voice and silencewithout conflicting with each other is not always realistic. Silence suppression will be discussed in a latertip.Most enterprise designers do not perform these calculations. The vendor provides the necessaryinformation. The designer does have some freedom, such as selecting the compression technique forvoice 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. Thisworked well for decades until the areas under city streets became saturated with copper cables, onecopper pair per call. Starting in the 1950s, AT&T Bell Labs developed a technique to carry more voicecalls over copper wire. They developed digitized voice technology through which 24 digital calls can becarried 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 thebandwidth for the 24 calls is 1.544 Mbps. This worked well for domestic connections. The T1 technologythen became the mechanism for long-distance domestic transmission.Most of the early voice compression technologies were designed for undersea cables, where bandwidthwas limited and expensive. Voice compression technologies were created to reduce this bandwidthrequirement. Voice compression is also used for digital cell calls, operating at about 8 Kbps instead of 64Kbps. So voice compression is not new.As the PBX market has moved into an IP-based environment, voice compression has become attractivefor WAN transmission. Voice compression can be used on a LAN, but since LANs have so much availablebandwidth, it is not commonly applied to the LAN.The quality of a PSTN voice call provides enough analog bandwidth to understand the speaker in anylanguage. It is also enough bandwidth for speaker recognition. The analog bandwidth delivered by thePSTN is about 3.4 KHz. This is considered toll quality. Voice compression can reduce the speech qualityand may affect speaker recognition, so there is a limit to how much bandwidth reduction is possiblebefore callers complain about voice quality.The CODEC (COder/DECoder) is the component in an IP phone that digitizes the voice and converts itback into an analog stream of speech. The CODEC is the analog-to-digital-to-analog converter. TheCODEC may also perform the voice compression and decompression.There are several voice digitization standards and some proprietary techniques in use for VoIPtransmission. Most vendors support one or more of the following ITU standards and avoid proprietarysolutions:• G.711 is the default standard for IP PBX vendors, as well as for the PSTN. This standard digitizesvoice into 64 Kbps. There is no voice compression.• G.729 is supported by many vendors for compressed voice operating at 8 Kbps, 8 to 1compression. With quality just below that of G.711, it is the second most commonlyimplemented standard.• G.723.1 was once the recommended compression standard. It operates at 6.3 Kbps and 5.3Kbps. Although this standard further reduces bandwidth consumption, voice is noticeablypoorer 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 previouslydescribed standards deliver an analog sound range of 3.4 kHz, G.722 delivers 7 kHz. This versionof digitized speech has been announced by several vendors and will become common in thefuture.
It is important to note that all of the voice digitization transmission speeds are for voice only. The actualtransmission 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 apossible 5.0 is considered to be toll quality. Voice compression will affect the MOS. An MOS below 4.0will 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 phoneG.711 64 Kbps 4.4 0.75 msG.729 8 Kbps 4.2 10 msG.723.1 6.3 Kbps5.3 Kbps4.03.530 msThis table illustrates two points. First, as the voice is compressed, the voice quality (MOS) decreases. TheMOS in the table does not include network impairments such as jitter and packet loss. Theseimpairments will further reduce the voice quality. The VoIP network designer should choose acompression technique with a higher MOS so the network impairments will not reduce the voice qualityto an unacceptable level.Second, voice compression also adds delay to the end-to-end call. The table shows the sampling delayfor one phone. This delay is doubled for the two phones of a call. This end-to-end delay needs to belimited. As compression increases, the delay experienced in the IP network needs to decrease, whichincreases the cost of transmission over the WAN, but not the LAN. The delays shown in the table are thetheoretical minimum. The actual delays experienced will probably exceed 30 ms, no matter whatcompression 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 itcomes with some costs in voice quality reduction and increased end-to-end delay.Inicio6.-VoIP performance testing fundamentalsVoIP network performance testing can mean the difference between a VoIP system working at a highlevel QoS and a weak system that runs so poorly customers could take their business elsewhere. Thisguide discusses why it is important to run regular performance testing and some of the ways it can bedone.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 theinitial 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 ifthe 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 PBXor 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 behelpful 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, andthe ability to deploy a new generation of converged applications. But no business can afford to have itsvoice services compromised. Revenue, relationships and reputation all depend on people being able tospeak to each other on the phone with five 9s reliability.Thus, every company pursuing the benefits of VoIP must take steps to ensure that their convergednetwork delivers acceptable call quality and non-stop availability.
A virtual network test bed is particularly useful for taking risk outof both initial VoIP deployment and long-term VoIP ownership.Essentially, such a test bed enables application developers, QAspecialists, network managers and other IT staff to observe andanalyze the behavior of network applications in a labenvironment that accurately emulates conditions on the currentand/or planned production network. This emulation shouldencompass 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 productionenvironment, validating vendor claims, comparing alternative solutions, experimenting with proposednetwork enhancements, and actually experiencing the call quality that the planned VoIP implementationwill deliver.Following are seven best practices for applying virtual network test bed technology to both initial VoIPdeployment and ongoing VoIP management challenges:1. Capture conditions on the network to define best-case, average-case and worst-case scenariosConditions in a test lab wont reflect conditions in the real-world environment if they are not based onempirical input. Thats why successful VoIP adopters record conditions on the production network overan extended period of time and then play back those conditions in the lab to define best-, average-, andworst-case scenarios. By assessing VoIP performance under these various scenarios, project teams canreadily discover any problems that threaten call quality.Seven best practices for arisk-free VoIP deployment1. Capture conditions onnetwork to define scenarios2. Run VoIP services in atesting lab under real-worldscenarios3. Analyze call quality4. Validate call quality5. Repeat to validate qualityremedies6. Do pre-deploymentacceptance testing7. Continue applying abovebest practices
2. Use the virtual network to run VoIP services in the testing lab under those real-world scenariosOnce the networks best-, average-, and worst-case scenarios have been replicated in the testenvironment, the project team can begin the process of VoIP testing by running voice traffic betweenevery set of endpoints. This can be done by actually connecting phones to the test bed. Call generationtools can also be used to emulate projected call volumes.3. Analyze call quality with technical metricsOnce VoIP traffic is running in an accurately emulated virtual environment, the team can apply metricssuch as mean opinion score (MOS) to pinpoint any specific places or times where voice quality isunacceptable. 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 callsTechnical metrics alone can be misleading, since the perception of call quality by actual end users is theultimate test of VoIP success. So the virtual environment should be used to enable the team to validatefirsthand the audio quality on calls between any two points on the network under all projected networkconditions. 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 remediesA major advantage of a virtual environment is that various fixes can be tried and tested withoutdisrupting the production network. Testing in the virtual environment should therefore be an iterativeprocess, so that all bugs can be fully addressed and the rollout of VoIP in the production environmentcan be performed with a very high degree of certainty.6. Bring in end users for pre-deployment acceptance testingSince voice quality is ultimately a highly subjective attribute, many VoIP implementation teams havefound that it is worthwhile to bring in end users for acceptance testing prior to production rollout. Thisgreatly reduces the chance of the dreaded VoIP mutiny syndrome, where end users balk at call qualitydespite 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 managementprocessTo maintain VoIP quality over time, IT organizations must incorporate the above best practices into theirchange 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 plannedrelocation of staff -- will not adversely impact end-to-end VoIP service levels.Its important to note that while a virtual network test bed will pay for itself by virtue of its support forVoIP and convergence alone, this technology has many other uses that deliver substantial ROI. Theseuses include the development of more network-friendly applications, better planning of server movesand data center consolidations, and improved support for merger and acquisition (M&A) activity. Thesesignificant additional benefits make emulation technology an extremely lucrative investment for ITorganizations seeking both to ensure the success of a VoIP project in the near term and to optimize theiroverall 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 examineyour statistics. One of the worst statistics you can consider as a means to determine your networkhealth is utilization.There are other statistics that are much more valuable. It isimportant to look at utilization, but this is only a small piece ofhealth.The problem with utilization is twofold. First, it is nearly impossible to determine when the workstationis actually in use. Even if someone is sitting at his desk, he may be on the phone and not using thenetwork. Also, many users work locally and then save their work to the network when complete. So inutilization you have to know when the network is really in use to determine how much of the bandwidthis being consumed. Look at the following two diagrams, for instance.Figure 1. Averages over one weekFigure 2. Utilization averages over one monthMore on VoIP performancetestingStop VoIP anomalies beforethey impact performanceMore VoIP tips
In Figure 1, above, the utilization was measured on the inbound side for a week. Figure 2 shows thesame 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 processingbecomes 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 discardpackets as a function. When the buffers get too full, they will drop packets and request a retransmissionfrom 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 anyport 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 biterrors. These may be expressed as InErrors and OutErrors. Not all manageable systems will allow you todrill 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 connectedon that port. A brief word about cable testing: Make sure the tester has the latest revision of softwareand firmware and has been calibrated recently. You also want to be sure that your interfaces and/orpatch cords are relatively new. Each has a limited number of mating cycles, and a channel may look badwhen in fact it is not.Next, check your duplex configurations. Duplex mismatches and/or channels that have auto-negotiatedto half duplex will further limit your operations. It is important to have full duplex links. A hard setting ineither the switch or at the workstation, or faulty cabling, including channels that exceed the maximumdistance, can cause half duplex links.After you fix your errors, you will want to take another network pulse for 30 days. The reason that Irecommend a 30-day window is to allow for such things as month-end processing and other functionsthat 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 expertsfor advice. Read on to find out what suggestions were made to remedy their VoIP performance testingissues.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. Howyou 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 willbe routed over your internal network rather than costly tie lines, you can test using a SIP to PSTNgateway (such as the MX25.)This configuration could look like this:Existing PBX ← T1 PRI → MX25 ← SIP over WAN network → MX25 ← T1 PRI → Existing PBXPerhaps you have a single site and you want to keep your existing PBX and connect long distance callsthrough an Internet telephony service provider that provides superior rates. In this case, you could use aSIP 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) totest the functionality before cutting over service. In this case, the configuration could look like this:Existing PBX ← T1 PRI → MX250 ← T1 PRI → PSTNUsing this approach, the existing PBX continues to function as it always has and only dial plan entries arerequired to route calls between systems. This allows for certain employees to learn the new VoIP systemand 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 beworking fine when it first went in, but recently, certain people have been complaining about soundbreakup whilst talking to customers on the phone. I have also had similar problems, but thought it wasdue 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 checkto make sure that the network is doing alright? Also are there any software utilities that would help uswith day to day analyzing?First and foremost -- I would suggest that you have someone come and test your cabling channels. Thatwill be the least expensive and could be the most worrisome component. Even if the channels testedfine when first installed, they can degrade over time with moves, adds and changes.The other thing you didnt mention was if this occurs only on the intra-office calls or only on outsidecalls. 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 yourswitch SNMP data for errors. These will also give you a good idea of what the culprit may be. If this ishappening to everyone in the building -- start looking for common denominators such as networkinterface cards in the switch.Inicio
7.-Session border control: The good, the bad,the uglyMike Jude, Wireless ExpertPrior to enterprise adoption of VoIP, session border control was considered arcane at best. In fact, shortof actually engineering interfaces between carrier networks, border control was simply assumed tohappen somewhere; after all, who cares how telephone carriers actually route traffic or managenetwork handoffs? Now, border control is becoming a critical aspect of securing enterprise networksand enabling traffic conditioning so that traffic flows smoothly between enterprise networks, carriernetworks and the PSTN. Still, many IT professionals actively avoid session border control, and with goodreason. While session management is an important arrow in the IT professionals quiver, it has severalissues that may argue against enterprise self-provision in some situations.The good: Why session border control mattersSo why is session border control (SBC) important? Without dwelling terribly long on the subject, SBC isan important way for IT to secure its enterprise network. Services such as VoIP have generally hadproblems 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 andcompletion or can make such new capabilities as unified communication problematic. Althoughtunneling through a firewall is certainly possible, doing so can compromise data security. SBC can notonly enable VoIP to bypass data firewalls in a way that does not compromise security, it can actuallyprovide more control over voice services generally by aggregating voice traffic. This is all to the good.The bad: Obstacles of session border controlHowever, 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-forgettechnology; as additions, moves and changes of voice service occur, the SBC must be configured torecognize 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 thisintroduces latency into the connection. These problems are certainly solvable, but once again, SBCrequires 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 bordercontroller. For the enterprise, it is obviously desirable to be able to secure network connections, yet thecarrier -- whose network is being connected to -- is also concerned about such things as QoS, lawfulintercept of voice traffic and management of the voice connection.For these reasons, carriers who offer VoIP connectivity often want to manage the session bordercontroller or specify the controller that the enterprise will use. This is clearly at odds with an enterprisethat 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 asaccess to 911 services and call intercept.Although the battle over control has generally been won in favor of enterprises, many carriers who offerSIP-based connections often make enterprise adoption of SBC technology more of an ordeal than itneeds to be. Almost every SBC vendor has developed a rather complete repertoire of support solutionsto ensure that carrier concerns are addressed; however, it is still possible to find carriers whose SIPtrunking services come with recommended or required SBC vendor solutions.Complicating this situation is the introduction of cloud-based session control. In this scenario, the SBCfunctionality is provided through a cloud service. Advantages are that the enterprise can offload a greatdeal of the management overhead associated with SBC maintenance. The drawback is that VoIP trafficlatency can increase dramatically as it transits a much larger network.Where to go for session border controlNevertheless, SBC is an important solution for the IT professional. Although there are situations where itis simpler to depend on the carrier to provide session control, there are many where the virtues ofenterprise 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-basedtelephony will want to take a hard look at SBC technology as well as vendors for such technology. TopSBC 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 serviceorganizations that will provide basic tutorials and/or design support. Interested readers are invited tocontact this author for vendor contacts if they wish.Inicio8.-PSTN vs. VoIP: Whats best for yourbusiness?Kara DeyermenjianAn increasing number of businesses are opting to replace their Public Switched TelephoneNetworks (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 andwas notorious for dropped calls and poor call quality. Significant strides have been made in the world ofVoIP, however, and there are plenty of reasons why making the change could be helpful. Areas whereVoIP currently has a leg-up on PSTN include advantages in scalability, cost and special featureavailability.On the other hand, many enterprises want to stick with their plain old telephone service(POTS), (servicethat runs over the PSTN). The well-known technology has built-in reliability, security and emergencylocation services. Just because something is plain and old doesnt necessarily mean its time to rip andreplace.
Are you still on the fence about whether or not to make the switch? Our tech-comparison helps youweigh the pros and cons. Its 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 comparisonInicio9.-Wireless voice over IP: What 802.11ac willdo for VoIPBrad Casey, Network SecurityFeature VoIP PSTNConnectivity type Internet connectivity Dedicated telephone linesRequired bandwidth Requires about 10 Kbps in eachdirectionTypically requires 64 Kbps in eachdirectionPricing Free VoIP-to-VoIP calling (local andinternational), butcalls to mobileand landline phones have nominalsubscription fees of around 1.2cents to 2.6 cents a minute.No free calls can be made. Costlyinternational calling. Monthlyphone plans usually cost around$25 to $30 per month dependingon service provider.Scalability Upgrades usually require morebandwidth and simple softwareupdates.Upgrades require purchasingmore hardware and dedicatedlines, which can be very complexand costly.Remote extensions This feature is typically standard. This feature typically requiresdedicated lines for each extensionand is very pricey.Business continuity/disasterrecoveryService terminates when Internetconnectivity (power) is lost.Organizations must have a VoIPdisaster recovery plan.Service usually remains activeduring power outages becausephone jacks do not requireelectricity. But cordless phonesdo and would be unusable.Call waiting Most VoIP options offer free callwaiting, such as Google Voice andSkype.Available at extra costCall forwarding Some VoIP options provide freecall forwarding (Google Voice),while others offer it for an extrafee or through a subscription(Skype).Available at extra costCall transferring Some VoIP options provide freecall transferring (Google Voice),while others do not support calltransferring at all (Skype).Available at extra costEmergency calling Depends on the service, butemergency calling is usually notprovided by VoIP or isverylimited (Skype). 911 calls are alsotypically untraceable.Emergency calling is enabled, andservices are traceable to location.
With the fast-approaching ratification of the IEEE 802.11ac standard, many applications that wereconsidered throughput hogs in enterprise environments will theoretically cease to consume as manyresources. In fact, depending on the processing power of the end device, applications heavily reliant onaudio 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-Fistandard may not have been completely realized as of yet, but rest assured that voice over IP (VoIP) willfind its own niche within this new technology.Current wireless voice over IP developmentsCurrently, the average end user has the ability to engage in wireless VoIP calls in residential and/or Wi-Fihotspot scenarios with profound regularity. Two of the more prominent applications used by commonend users are Skype and Windows Live Messenger. While Skype has not yet made their core protocolpublic, a simple Wireshark capture reveals thatTCP is used for the control signal, while UDP is used fordata transfer. This dual utilization of TCP and UDP has gained in popularity in recent years, since itseems to compliment the older SS7 method of using a physical control signal along with a separate -- butalso 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 toocrowded, items such as Quality of Service (QoS) and overall throughput availability become adverselyaffected.With the ratification of the new IEEE 802.11ac standard (Gigabit Wi-Fi) on the immediate horizon, theexpectation is that some of the QoS issues found within currently crowded wireless LANs will bealleviated. The new standard supports up to eight spatial streams, as opposed to the four spatialstreams supported by its predecessor, 802.11n. The increase in spatial streams will allow for lesscompetition among nodes associated with the same AP, and it will allow wireless administrators to bondspatial streams, thereby allowing bigger pipes across the wireless spectrum. Furthermore, the 802.11acstandard operates within the5GHz frequency band, as opposed to the 2.4 GHz band that its predecessoroperates in. This will provide the wireless VoIP end user the opportunity to converse with less concernfor overlapping channels than would otherwise be the case under the 802.11n standard.Wireless voice over IP security issuesMany of the security issues with wireless VoIP have very little to do with the new standard, andtherefore 802.11ac will do very little, if anything, in the way of addressing them. As with any othercommunication conducted wirelessly, the primary vulnerability resides in the fact that everyone withinthe 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 isweak. 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 helpwith whatever encryption mechanism is used by the VoIP applications themselves. More specifically, thehigher throughput available within 802.11ac will allow for faster processing of the network overheadthat invariably comes with any encrypted signal. So, in the case of Skype calls, the end user mayexperience a considerable jump in performance, since Skype currently encrypts all calls by default. In thecase of Windows Live Messenger, the end user may not notice as much of an improvement, sinceMessenger is unencrypted by default and therefore less consuming of network resources.
ConclusionWireless VoIP has gained significant amounts of traction within the small and medium-sized businessmarket, because Cisco and other large companies have developed some fairly robust WVoIP solutionsthat center on actual wireless phones that associate with APs in the same way that a laptop associateswith APs currently. This involves the purchase of a few other network devices, such as the Cisco UnifiedCommunications Manager, so that the processing of wireless packets is handled more quickly and in amore orderly way. For the typical residential user however, the new 802.11ac standard should prove tobe a boon to those who engage in WVoIP calls at their favorite Wi-Fi hotspots.Glosario:http://searchunifiedcommunications.techtarget.com/definition/VoIP-GlossaryInicioRecopilación de fam/ Mayo 2013