Maybe someone has run into this, I have a standalone 9.5 for now with approx 20 voip phones and growing, but when they go off hook they get clipping and jitter, we have it running into a 3 com switch currently. Any help would be appreciated.
Some more info would be needed on this but let me assume afew things. You have set up QOS on the 3com and the VOIP phones are in the their own Vlan. That said verify latest and greatest firmware on your Medpro board/s. Below is more than you probably ever want but...
TOP PROBLEM IP VOICE QUALITY PROBLEMS
Resource Materials:
Avaya IP Voice Quality Network Requirements, White paper, Issue 2.0, August 2002.
4620/2620SW/4621SW IP Telephone User Guide, 555-233-781, Issue 3, April 2006, page 62.
Avaya VoIP Monitoring Manager User Guide, 555-233-510, Issue 2, Augus 2002.
The critical objective factors in assessing VoIP quality are delay, jitter and packet loss. To ensure good and consistent levels of voice quality, one must be able to address these identified factors. Note that these suggestions hold true for both LAN only and LAN/WAN connectivity. Avaya suggests the following network requirements:
I. NETWORK PACKET DELAY
Packet delay is the length of time it takes a packet to traverse the network. Each element of the network adds to packet delay including switches, routers, distance traveled through the network, firewalls, and jitter buffers (such as those built into H.323 audio applications like the Avaya IP SoftPhone™ or Microsoft NetMeeting). Router delay depends not only on hardware, but also on configurations such as access lists, queuing methods, and transmission modes. Delay (latency) can have a noticeable affect but can be controlled somewhat in a private environment (LAN/WAN) because the company or enterprise manages the network infrastructure or SLA. When using the public network, there are inherent delays that one cannot control.
The following chart suggests guidelines for one-way network delay. Again, there is a trade-off between voice quality and the technical and monetary constraints with which businesses confront daily. All measurement values are between endpoints because this document assumes that IP telephony has not yet been implemented. All values therefore reflect the network’s performance without endpoint consideration. Also, “Business Communication Quality” is defined as less than toll but much better than cell-phone quality.
Network delay: Between endpoints, meaning LAN/WAN measurements not including IP phones.
a). 80ms (milliseconds) delay or less can, but may not, yield toll quality.
b?????80ms to 180ms delay can give business communication quality. This is much better than cellphone quality and in fact is very well suited for the majority of businesses.
c). Delays exceeding 180ms may still be quite acceptable depending on customer expectations, analog trunks used, codec type, etc.
]
The ITU-T has recommended 150ms one-way delay (including endpoints) as the limit for “excellent” voice quality. This value is largely misinterpreted as the only range to calculate a network delay budget for IP telephones. A network delay budget of 230ms proved almost imperceptible in lab experiments at Avaya. One-way delays in excess of 250ms can cause the well-known problem of “talk-over”, when each person starts to talk because the delay prevents them from realizing that the other person has already started talking. Certainly long WAN transports must be considered as a major contributor to the network delay budget. Some WAN service providers can lower delay in their network if it is negotiated and recorded as part of the companies SLA (Service Level Agreement). Even so, staying within 150ms (end to end) may not be possible. Finally, end-to-end delay over 400ms can cause port network instability. A network assessment is highly recommended to measure latency (and other factors) and make recommendations to solve any latency issues before implementing a VoIP solution.
II. NETWORK JITTER
Jitter is a measure of variance in the time it takes for communications to traverse from the sender
(application) to the receiver. Jitter is thought of as the statistical average variance in delivery time between packets or datagrams. Jitter can create audible voice-quality problems if the variation is greater than 20ms (assuming an existing 20ms packet size). Symptoms of excessive jitter are very similar to symptoms of high delay, because in both cases packets are discarded if the packet delay exceeds half the jitter buffer size.
To compensate for network jitter, many vendors implement a jitter buffer in their H.323 voice
applications. The purpose of the jitter buffer is to hold incoming packets for a specified period of time before forwarding them to the decompression process. A jitter buffer is designed to smooth packet flow. In doing so, it can also add packet delay. Jitter buffers should be dynamic to give the best quality, or if static, should generally be sized to twice the largest statistical variance between packets. Router vendors have many queuing methods that alter the behavior of the jitter buffer. It is not enough to just select the right size of jitter buffer, one must also pair an appropriate queue-unloading algorithm type with the jitter buffer. The network topology can also affect jitter. Because there are fewer collisions on a data-switched network than on a hub-based network,
there will be less jitter on the switched network.
The Avaya™ G600 and Avaya™ G700 Media Gateways, Avaya™ IP600 Internet Protocol
Communications Server, Avaya™ IP SoftPhone software and Avaya™ 4600 Series IP telephone have all incorporated dynamic jitter buffers to minimize delay by reducing the jitter buffer size as the network allows. Note that this feature can exacerbate problems in an uncontrolled network.
III. PACKET LOSS
Network packet loss occurs when packets are sent, but not received at the final destination due to some network problem. Qualifying problems caused by occasional packet loss are difficult to detect because each codec has its own packet loss concealment method. Therefore, it is possible that voice quality would be better using a compression codec (G.729A) compared to a full bandwidth G.711 codec. Several factors make packet loss requirements somewhat variable, such as the following:
a). Packet loss requirements are tighter for tones (other than DTMF) than for voice. The ear is less able to detect packet loss during speech (variable-pitch), than during a tone (consistent pitch).
b). Packet loss requirements are tighter for short, continuous packet loss than for random packet loss over time. Losing ten contiguous packets is worse than losing ten packets evenly spaced over an hour time span.
c). Packet loss may be more noticeable for larger voice payloads than for smaller ones, because more voice is lost in a larger payload.
d). Packet loss may be more tolerable for one codec over another.
Even small amounts of packet loss can greatly affect TTY (TDD) device’s ability to work
properly.
e). Packet loss for TCP signaling traffic increases substantially over 3% loss due to retransmissions.
Network packet loss: The maximum loss of packets (or frames) between endpoints should be
a). 1% or less can yield toll quality depending on many factors.
b). 3% or less should give Business communications quality. Again, this quality is much better than cell-phone quality.
c). More than 3% may be acceptable for voice but may interfere with signaling.
IV. ECHO
The two main types of echo are acoustic and impedance although the sources of echo can be many. Echo will result when a VoIP call leaves the LAN through a poorly administered analog trunk into the PSTN.
Another major cause is from an impedance mismatch between four-wire and two wire systems. Echo also results when an impedance mismatch exists in the conversion between the TDM (Time Division Multiplexing) bus and the LAN, or the impedance mis-match between a headset and its adapter. Impedance mis-match causes inefficient energy transfer. The energy imbalance must go somewhere and so it is reflected back in the form of an echo. Usually the speaker hears an echo but the receiver does not. Echo cancellers, which have varying amounts of memory, compare the received voice with the current voice patterns. If the patterns match, the canceller cancels the echo. Echo cancellers aren’t perfect, however. Under some circumstances, the echo gets past the canceller. The problem is exacerbated in VoIP systems. If the one-way trip delay between endpoints is larger than the echo canceller memory, the echo canceller won’t ever find a pattern to cancel. Avaya’s G600, G700, Avaya IP600 Internet Protocol Communications Server, Avaya IP SoftPhone software and Avaya 4600 series IP telephone all incorporate echo cancellers designed for VoIP to improve voice quality.
V. NETWORK DUPLEX
The ideal LAN network for transporting VoIP traffic is a network that is fully switched from end-to-end because it significantly reduces or eliminates collisions. A network that has shared segments (hub-based) can result in lower voice quality due to excessive collisions and should be avoided. Ethernet connections from Avaya hardware default to auto-negotiation for speed and duplex to work with the network endpoints right away. Avaya recommends, however, that connections become set values for static links because of known problems with the way auto-negotiation was designed. The CLAN, Media Processor, Crossfire, IPSI etc. connections should be set to 100Mbps and full duplex both in MultiVantage Software AND at the Ethernet data switch to which it terminates. Note that IP Telephones use auto-negotiation, and specific older versions of circuit cards may require different speed and/or duplex settings. To determine what speed/duplex settings are configured, the following commands executed in Communication Manager provide detailed information:
list ethernet-options
ETHERNET OPTIONS
Enable
Eth Pt Type Slot Code Sfx Auto Speed Duplex
------ ---- ---- ---- --- ---- ----- ------
y C-LAN 01A02 TN799 D n 100Mbps Full
y C-LAN 02A02 TN799 D n 100Mbps Full
y MEDPRO 01A04 TN2302 n 100Mbps Full
y MEDPRO 02A03 TN2302 n 100Mbps Full
get ethernet-options 1a04
GET ETHERNET OPTIONS
Administered Actual
Auto-Negotiate? n n
Speed: 100 Mbps 100 Mbps
Duplex: Full Full
Link Integrity: Active
VI. CODEC SELECTION
Depending upon the bandwidth availability and acceptable voice quality, it might be worthwhile to select a codec that produces compressed audio.
a). A G.711 codec produces audio uncompressed to 64 kbps
b). A G.729 codec produces audio compressed to 8 kbps
c). A G.723 codec produces audio compressed to approximately 6 kbps
The following table provides comparisons of several voice quality considerations associated with some of the codecs supported by Avaya products. It should be noted that toll-quality voice must achieve a MOS (Mean Opinion Score) of 4 or above. MOS scoring is a long-standing subjective method of measuring voice quality.
Generally, G.711 is used within LANs because bandwidth is abundant and inexpensive whereas G.729 is used across WAN links because of the bandwidth savings and good performing voice quality.
VII. TROUBLESHOOTING TECHNICAL TIPS
Several voice quality issues are related to administration in one way or another. In other words, the administration needs to be adjusted in order to provide the best quality voice on the network. This would lead to the critical question, was a network assessment done and if so, did the location experiencing problems add any significant traffic to their network afterwards that requires another one? Either way, if it’s a voice quality issue and the affected location is at the latest firmware (available on the support.avaya.com website) when it comes to Media Processors (MEDPROS), Crossfires, and IP phones, then the following steps may be used to monitor voice quality issues in order of simplicity:
1). Execute a list trace of a bad VoIP call and look for jitter and/or packet-loss within the trace. The “list trace station” command in Communication Manager displays the packet loss and jitter buffers. These buffers are updated continuously. So the 10 entries displayed will be the last 10 entries during the sample interval. This is useful in voice quality troubleshooting, because remember that the critical objective in assessing VoIP quality are delay, jitter, and packet loss. In the example shown below, the average jitter was less than 10 seconds and packet loss was zero percent.
2). In the event you experience poor audio quality during a call , specifically, you hear an echo, static, sudden silences and gaps in speech, clipped or garbled speech, etc., various potential network problems might be causing the problem. If the IP phone is a 4620/4610 model, then you can go into the menu of the phone and monitor the statistics in real time by viewing the network audio quality to diagnose or troubleshoot VoIP problems. Select Network Audio Quality from the Options Main screen (accessed by pressing the phone’s Option button). If administered, the Audio Status screen displays.
Note:
Note: The Network Audio Quality button displays only when you are on a call
(off-hook).
3). Gather a network sniff on the phone port or mirrored port. The customer’s network department should be able to handle this request. However, if the customer prefers an Avaya technician then a case will need to be built in order to dispatch a technician onsite that is trained in using Avaya’s Ethereal.
4). Gather a sniff of the Medpro/Crossfire port and phone port (both filtered by the phone IP address). Once again, the customer’s network department should be able to perform this sniff but if they want Avaya to do this a tech will need to be dispatched again.
5). And then there is always the Avaya network management tool, VoIP monitoring (VMON), which helps maintain a properly functioning VoIP network. It is a Voice over IP (VoIP) Quality of Service (QoS) monitoring tool. It enables you to monitor and review the quality of a call on an Avaya VoIP Network. Using VMON you can view the QoS data (i.e. the Jitter, Round Trip Time (RTT) and Packet Loss experienced at the endpoints and during a session. With this information, you can begin to troubleshoot and isolate problems.
If all else fails, then it may be time to get the Network Integration Center (NIC) involved because network troubleshooting is now needed or engage the T3 services backbone for additional assistance.
**The question may not be the technology, but the competency of the support people.**
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.