by Danny Buetler, Alianza
Voice over IP (VoIP) allows digitized voice conversations to be transmitted via Packet Switched IP networks. Due to the unique nature of IP-based networks, certain minimum network requirements must be met in order to preserve the end-user’s Quality of Experience (QoE).
There are three primary factors that contribute to the QoE of a VoIP call. The factors are latency (or delay), packet loss, and jitter. QoE is measured on the five-point Mean Opinion Score (MOS) scale defined in the ITU-T recommendation P.800. A MOS score of 4.0 is considered “Toll-Quality,” the quality you would hear on a wired landline from your local telephone company. A MOS score between 3.0 and 3.7 is considered normal for cell phone use.
Latency
Latency is the delay of the voice signal from the person on one side of the conversation to the person on the other end of the conversation. Latency is caused by three primary factors: the inherent delay of the IP-based network, the jitter buffer, and the codec used. G.114 is an International Telecommunications Union recommendation regarding one-way transmission time. According to this recommendation, if delay is kept below 150ms, user experience is unaffected. However, as delay increases, user acceptance is increasingly affected.
Alianza recommends latency of less than 150ms. The Service Provider has the greatest influence on network latency. Factors affecting latency include bandwidth, network speeds, and, to a large extent, physical distance. Alianza recommends the Service Provider use QoS mechanisms such as DiffServ, IntServ, or ToS in order to decrease latency. Specifically, QoS benefits the most in limited bandwidth situations, such as the last mile, and should be implemented in these situations first. The Service Provider should also ensure that older hardware on the network is not creating a bottleneck. Older devices are typically slower and introduce more latency.
Packet Loss
As VoIP uses the IP-based network, each voice conversation needs to be packetized (broken up into small data packets) and compressed. Packet loss is when one or more of these packets are lost during transmission. Packet loss can have a detrimental effect on the end-user’s QoE. Packet loss can come from network congestion or connectivity errors between endpoints. Packet loss can also come from the jitter buffer. As a general rule, less than 1 percent packet loss is considered acceptable.
To decrease packet loss, the Service Provider can ensure that sufficient bandwidth is available to meet network requirements at peak usage.
Jitter
Jitter is variation in the order and time in which packets are sent and received. Packets are numbered and sent chronologically as they are created. Because of network congestion, or the ability of packets to take different routes over the network, the packets may arrive out of order or with varying delays. In order to maintain a high QoE for the end-user, voice packets must arrive in a fairly consistent manner.
Unfortunately, the nature of routing and queuing methods in the various networks between endpoints introduces varying amounts of delay. Packets that were sent exactly 10ms apart may arrive with varied spacing. For good call quality, Alianza recommends that jitter be less than 20ms. Acceptable jitter is between 20 and 50ms. QoE will begin to degrade significantly as calls approach 50ms of jitter, and QoE will be severely impacted beyond this point.
To decrease jitter, the Service Provider can ensure that the same QoS mechanisms used to decrease latency and packet loss are in place.
Additional Factors
Some additional factors to consider when evaluating the Quality of Experience are:
-
End-Point Devices
- Local Network Gateway/Router to the Internet
- Local Upload Speed
- ISP Network and Quality Data Connections to the Internet Backbone
- Data Center
- PSTN Carrier Quality
- Recommended Parameters Summary
VoIP Testing
Testing is generally required to understand how a Service Provider’s network is performing and to expose any areas of weakness. Alianza recommends that the Service Provider run end-to-end tests to ensure that the network is optimized for voice traffic.
There are a wide variety of VoIP testing tools available. Alianza has standardized on the Cisco IP-SLA functionality available in their routers for VoIP testing. IP-SLA simulates VoIP traffic providing details around delay, jitter, and packet loss and also provides a MOS.
The Cisco IP-SLA functionality requires two routers, one on each end, and mimics actual call functionality by simulating the characteristics of VoIP UDP Packets. Alianza has an IP-SLA enabled router as part of its platform. It is the responsibility of the Service Provider to provide a route in their network as close to the end-user as possible.
Following are the details on how to configure your router for performing IP-SLA testing with Alianza:
Setup:
Enable IP-SLA Configuration on your Cisco router.
Firmware minimum: Version 12.4(4)T
Detailed minimum firmware version requirements for IP-SLA can be found at:
http://www.cisco.com/en/US/docs/ios/ipsla/command/reference/sla_book.html
Ensure that two UDP Ports are open for communication with Alianza.
Port 1967:IP-SLA Control Port
Any additional UDP port greater than 1024 of your choosing
Enable IP-SLA on your router.
Enabling IP-SLA differs with the firmware revision but it is usually “ip sla responder”
Send Alianza the following information:
The second port number of your choosing from #2 above.
The public IP address of your router.
IP-SLA details are collected every minute directly from the Cisco router through SNMP. This information will be collected by Alianza over a predefined period of time (long enough to be statistically significant) and reported in graphical formats in order to provide an estimated QoE for the end-user. The Service Provider may choose to replicate IP-SLA testing over various parts of the Service Provider’s network, either serially or in tandem.
Satellite Network Considerations
The same techniques used on a standard packet switched network are used on satellite networks to ensure maximum quality with minimal impact to valuable network resources. Due to the physical limitations of satellite networks, it is especially important that satellite operators planning to support VoIP understand and configure QoS on their network.
In addition to the recommendations listed in this article, and due to the difference in technologies between typical networks and satellite links, the following additional recommendations are uniquely suited to satellite providers when incorporating VoIP onto a satellite network.
- Packet fine-tuning fills available timeslots and saves valuable bandwidth.
- Typically, the SIP/RTP packets (call flow) are intentionally very small. Especially on an Ethernet based network, if a few of the packets are dropped, the call is not impacted. On a satellite network, if this same technique is used, the network reaches an unnecessary early saturation. The “frames” in satellite links are much larger, but the timeslots available to each subscriber are available less frequently. By increasing the size of the voice packets to fill the available frames, more traffic can be sent. This modification increases call quality, since VoIP traffic is time-sensitive, and packets will be dropped if they do not have an available timeslot.
- Signaling control compensates for delay and provides security and consistency.
- Call control, or call signaling, is an integral piece in creating the perception of a high-quality call. The SIP standard compensates for outside of normal delays by allowing the call control flexibility in waiting for acknowledgments and making additional attempts before rejecting or terminating the call.
- Due to the nature of satellite technology, delay is inevitable on a satellite link. By keeping jitter and packet loss to a minimum, the delay is less noticeable and the overall voice experience can be very good.
About the author
Danny Beutler is the Senior Platform Engineer at Alianza, Inc., the provider of an award winning hosted voice platform. His background includes senior network and systems administration design and implementation. At Alianza, he is responsible for designing the architecture and implementing components of the core voice platform.