IP-Audio Connection Tests


The Telos Z/IP ONE represents the state of the art in high quality, low latency IP audio transmission. Its Agile Connection Technology (ACT) works within user set parameters to maintain the highest bit rate and the lowest latency possible over a given end to end IP path. That said, it’s still desirable to characterize each end of the IP connection prior to use, to see if there are any configuration issues or impairments to smooth packet transmission and reception.

Our experience is showing that most “Internet connection” troubles occur in the “last mile” and the local router. This implies that characterizing each end of a proposed IP connection is a valid way to pre-qualify that connection. It’s less important to check end to end (which the Z/IP ONE’s ACT does anyway) and more important to characterize each end’s connectivity with the Public Internet. The Public Internet itself rarely turns out to be a source of connection trouble.

Using a PC or laptop computer at each location to perform connection characterization tests is very valuable, and can reveal IP connection issues before they affect you live audio broadcast over IP.

While a speed test is a good place to start, there’s more to characterizing an IP connection than simply measuring upload and download speed. Packet jitter, especially over some time, is critical to know. A measure of dropped packets is important, too. Additionally, an understanding ofthe local router’s behavior can point out issues before they affect an on-air broadcast.

Many of the available online IP path tests require Java to be running as a plugin with your web browser. As Java is falling into some disfavor due to persistent known security issues, we present a few tests here that do not require Java.

This one is cool as it can be customized to run automatically at a set interval to give you speed over time. It's all php based.

http://testmy.net

This one is all HTML5 and works well...

http://speedof.me

While the following tests require Java in the browser, they are generally more comprehensive and test more parameters of interest.
Comprehensive test of speed, loss, latency, and jitter.


http://www.megapath.com/speedtestplus/

Comprehensive VoIP readiness test. This example shown was performed when a particular connection was busy with a lot of other Internet traffic, causing excessing jitter. IP¬Audio would work if more buffering at each receive end is dialed¬in.

https://www.voipreview.org/speedtest

Tests from nearest server for ping time and jitter


http://pingtest.net/

For a test of the local router’s configuration and performance, this comprehensive test is useful. It’s especially revealing of a recent phenomenon known as “buffer bloat”. Seems many modern routers are incorporating an excess of buffer memory that can significantly slow the progress of IP¬audio packets through the buffer. This occurs when there’s a lot other IP traffic on the connection. This test reveals the worst¬case buffer latency between the test location and the test server. Most of this latency is likely to be in the local router. There is some initiative among concerned users to have router manufacturers implement adjustment tools to control the amount of packet buffer in use. Too much packet buffer anywhere in an IP system can essentially “break” the smart way that TCP/IP is supposed to throttle automatically, with RTP/UDP packets getting caught up in the delay. This test requires Java as well.


http://netalyzr.icsi.berkeley.edu/

 

Interpreting Test Results

What should we look for when analyzing these results? Certainly sheer speed or bandwidth is critical. If we have only 100 kbps of upload bandwidth then we’ll have little or no margin for a 64 kbps audio bit rate as this will get packetized to about 80 to 100 kbps total. There’s no magic ratio of encoding rate to upload bandwidth, but we’d like to see at least a 100% margin, and that’s assuming there are no other users of this “last mile” connection.
As important is consistency of Round Trip Time as measured in some VoIP tests. Jitter can substitute for RTT. What’s desired is jitter of less than 20 ms, which is about 1 IP¬Audio packet. Higher jitter usually means there are other packets contending for attention in the upload or download path. The receive buffer on the far¬end codec will need to be increased by at least the worst¬case jitter figure. The Z/IP ONE’s ACT function will typically account for this automatically. Note that this ACT function is active only when using MPEG codecs (AAC, MP2 and MP3) when two Z/IP ONEs are connected together using the default protocol, TSCP.
Packet loss is important, but only if rises above a few percent over time. The AAC codecs in the Z/IP ONE are designed to work well in the presence of up to 5% packet loss.
The Netalyzr test from berkeley.edu shows a worst¬case network buffer measurement for both downlink and uplink buffers. This is the worst¬case that the test was able to cause, but could be higher under real¬world conditions. Again, higher buffer numbers are usually caused by too much other Internet traffic in and out of the router’s WAN port. Lower numbers here are better. Various routers will behave differently on this test and may indicate that a different router should be tried if the buffer times are uncomfortably high.
Remember, when using any of these tests, they reflect the IP path between your connection and the high¬bandwidth server at the other end. You’ll want to perform these tests several times and under similar conditions to your proposed broadcast. Results may vary from time to time of testing, and what may seem like a great connection on a Sunday afternoon may turn out to be woefully overloaded on a Monday morning. And, what may prove to be wonderful at 6am may be troublesome at 9am. This is why it’s always best to use a dedicated Internet connection, just as one would have used a dedicated ISDN or T1 connection before IP became widely available

 

Agile Connection Technology

The Telos Z/IP ONE incorporates Agile Connection Technology. This “saving grace” tech will get you through a lot of situations where the IP connection is less than perfect. If the codec’s receive buffer size needs to increase to handle additional jitter or latency, it will. If the encoder’s bit rate needs to decrease to account for less available bandwidth, it’ll do that, too. Indeed, when using the AAC algorithm, the Z/IP ONE will even switch codecs ¬ to HE¬AAC ¬ automatically if the avilable bandwidth falls below about 96 kbps. The means that the Z/IP ONE can automatically throttle from 320 kbps all the way down to 16 kbps, if absolutely necessary, to maintain an audio connection.

 

Summary

Even with the Z/IP ONE’s ACT features, you’ll want to spend a few minutes to ensure you have the best IP connection possible at any given location, whether it’s the studio or a remote site. Many potential issues are, indeed, within the control of the station engineer. From the choice of Internet supplier or connection to the proper configuration of a router and LAN, engineers can optimize the IP connection for a trouble¬free audio broadcast.



Return To