Remotes via IP

Publish date:

Remotes via IP

Feb 1, 2008 12:00 PM, By Doug Irwin, CPBE AMD

Image placeholder title

The APT Worldcast Eclipse features GUI user access.

In the January Trends in Technology I discussed the difference between TDM and IP in the context of a station's STL system. I asserted that with a LAN extension to the transmitter site or even a WAN with known and controllable characteristics it made sense to consider IP for an STL system (most certainly for backup systems). It may seem logical to apply the same thought to a remote broadcast, but remote broadcasting is really a different ball game. The nature of remote broadcasts is that they are always somewhat risky. Everyone knows that you are walking on a tightrope without a net below. We are all willing to accept a certain amount of risk when it comes to executing a remote; indeed, when you pull it off against the odds, it makes the winning result that much sweeter.

The means by which you could carry out a remote broadcast used to be fairly limited. You could contact the telephone provider to see if it could drop a broadcast loop at the proposed location. Whether they could or not was often predicated on whether or not there was enough time to do so. If the line was dropped in time, the results could be good (if you got a good installer) or they could be not so good, for a variety of reasons.

If you were lucky enough to have a licensed RPU channel and the proper equipment, then likely you could pull off remotes fairly easily, though quite often the audio quality wasn't that great. A �remote� really sounded like it was remote, in most cases. Interference from other users of the shared radio channels was always the wildcard to be wary of.

In the early 1990s, when ISDN started to see widespread use, the ordering issues were similar. The telephone provider had to be able to actually deliver ISDN at the proposed site, and there had to be enough time before the remote date to get the line installed and tested. The good thing about ISDN is that (assuming you have a good connection) you know what audio quality to expect ahead of time. Because ISDN provides a full-duplex connection, mix-minus and talkback could be provided to the remote site too, which was a nice improvement in functionality.

Current limitations

Image placeholder title

The CCS Suprima has IP, ISDN and X.21/V.35 connectivity.

At my station, we use ISDN frequently for remotes, but I know the future of remote broadcasting is wrapped up in the almost ubiquitous nature of the Internet. We don't make use of RPU, and I have found most programmers have been spoiled by the audio quality we get with ISDN codecs. The audio quality of RPU has become unacceptable in most cases. We're preparing ourselves for the inevitability of using the Internet for remotes, and you probably should as well.

Using the Internet for remotes, though, really represents a paradigm shift. Up to this point, the means by which audio was sent back to the station from the remote site was yours and yours alone (with the exception of those shared RPU frequencies). The audio quality was a function of the bandwidth - and the bandwidth was known ahead of time. Now, in making use of an Internet connection, you will contend with an unknown number of users, each of who will occupy varying amounts of bandwidth at random times, all through a pipeline with a fixed maximum bandwidth for its shared users. Sounds a little scary, but not surprisingly, many manufacturers of broadcast remote equipment have studied and attacked the problems associated with this shared usage successfully. Let's examine some of those problems.

When contending with other users for bandwidth in a bandwidth-limited system, there is an advantage in minimizing your own bandwidth requirements. For this reason, codecs that use the Internet for connectivity make use of many of the same audio compression schemes we've become familiar with that work over synchronous networks (such as ISDN or TDM).

Image placeholder title

Phoenix from AEQ features front panel or USB user access.

However, the packet-switched nature of the Internet (as opposed to the circuit-switched nature of the PSTN) complicates the situation considerably. The data stream that represents the audio output of the encoder is broken into pieces - called packets - and each packet has additional information appended prior to its injection into the network. That packet overhead is the same on a per-packet basis, so changing the packet size affects the overall bandwidth needed to move the packets.

Say you have an audio encoder with an output of 128kb/s, or 16 kilobytes every second (16KB/s). Now, say you break that data stream into 800-byte pieces; add overhead of (for example) 100 bytes to each of the 800 bytes of payload. So, now you've generated packets that add up to 18KB/s, for an increase in required bandwidth of 12.5 percent. Or, say you break the data up in to packets of 200 bytes; add 100 bytes per packet of overhead. Now the bandwidth requirement is 24KB/s, or a 50 percent increase over the size of the encoder output by itself.

An unfortunate characteristic of the Internet is that sometimes these packets are lost along the way, for various reasons. Ideally, you would want the packet size to be large because, as I just demonstrated, the overall bandwidth requirement is reduced. However, if one of those large packets is lost, then a substantial amount of the encoded audio data will be missing at the far end.

Image placeholder title

The Telos Iport features a 2RU form factor.

One aspect then, considered to be important in gaining success in transmitting audio across the Internet, is the ability to alter the packet size on the sending end, so that different network conditions can be met, and the effect of dropouts can be minimized. Some of the units actually adjust the packet size dynamically based on changing network conditions. In any case, the user needs to be able to adjust the packet size so the best compromise between packet size and overall bandwidth can be met.

Inevitably, some packets will still be lost though, and there are other mechanisms designed to further minimize the negative effects of packet loss. One such method is known as forward error correction (FEC). FEC is basically the addition of redundant packets to the data stream - the idea being that these redundant bits will effectively take the place of the packets that somehow end up missing at the far end. One can easily see that the addition of too many redundant packets could possibly create a problem in and of itself with respect to network congestion. Therefore, like packet size, the amount of FEC should be adjustable by the user, to best meet network conditions.

Oh, but it doesn't end there friends. The nature of the Internet also means the packets getting to the receive end may be late, or even out of order. For an audio stream, this is obviously a problem - one addressed by way of a packet jitter buffer. This buffer stores received packets for a certain amount of time, allowing late packets to catch up; out of order packets can also be re-sequenced prior to being sent to the audio decoder. The obvious problem here is that the buffer adds delay time, generally considered bad when doing remotes. Therefore, once again, a compromise must be struck between problems in the audio caused by late or out of sequence packets, and the amount of delay that can be dealt with at the remote site.

1 2 Next

Remotes via IP

Feb 1, 2008 12:00 PM, By Doug Irwin, CPBE AMD

Putting it all together

Image placeholder title

Access, from Comrex has optional AAC.

So let me summarize the problems with Internet transmission of audio and the techniques used to minimize them. First, there is network congestion, or plain lack of bandwidth. That issue is tackled by minimizing the necessary bandwidth, by using a lossy codec (or in the case of APT, making use of ADPCM) and striking a correct balance between bandwidth and packet size. Loss of packets is addressed to the extent practicable by FEC. Packet jitter is addressed with a jitter buffer.

All that said, network security is yet another issue. Your LAN is likely attached to a router that allows users on your network to access the Internet. The connections made through this router originate behind it - on the LAN side. The router will allow access to the Internet, and in turn it expects a response from the far end. But think about it: If you are in the field, and trying to connect to an IP codec connected to your network, and the router serves as a firewall, the connection will be refused. As far as that router is concerned, an intrusion is being attempted.

There are several ways around this. The first is to inform the network administrator that for the new IP codec to work, certain ports need to be open on the firewall, so the IP codec in the field can set up communication between itself and the studio codec. If your network architecture includes a DMZ, your network admin may allow you to place the IP codec on that subnet instead.

Image placeholder title

The Tieline IP codec is just one IP product from the company, which features Tieline Voice and Tieline Music algorithms.

The second way is a bit more complicated; consider this if your network administer doesn't want to play ball with you. A proxy server can be used as an intermediary. This proxy server is located outside the firewall. A session can be initiated by the studio codec to this proxy server; the proxy records the IP address (among other things) of the studio codec and actually maintains the connection thereafter. From the field, you connect to the proxy server, and it redirects the packet data to the studio codec, through the same connection it has kept open.

And there is a final way to do this, which may be the easiest way. Have an Internet connection put into the studio (like DSL or cable) and reserve its use for just the IP codec. Leave it completely isolated from the LAN, so you can forsake those network security issues. One problem with this method is that your Internet provider may not provide you with a static IP address. Either pick one that does, or make sure you know if and when the IP address has changed before you head out into the field.

Making use of the Internet for remotes can be looked at as a double-edged sword; while one has to take the time to learn about a whole new technology (and undoubtedly be tripped up a few times along the way), the universe of locations from which remotes can be done opens up dramatically. I for one believe that good remotes can make for good radio; and I'm quite sure that, 5 to 10 years out, the trepidation experienced in going out to do an IP remote for the first time will have long since evaporated.

Resource Guide

APT Worldcast Eclipseaptx.comIP, ISDN, X.21/V.35 1RU analog or AES-3 GUI Y Y Y Y Y - 24kHz Y N Y Musicam Suprimamusicamusa.comIP, ISDN X.21/V.35 1RU analog or AES-3 Web Browser Y Y Y Y Y - 24kHz Y N Y AEQ Phoenixaeqbroadcast.comIP, ISDN X.21/V.35 1RU analog or AES-3 Front Panel, USB Y Y Y Y N - 20kHz Y during setup N Y Audio TX STL-IPwww.audiotx.comIP 1RU analog or AES-3 Web Browser Y Y Y Y N - 48kHz N Y Y Telos Iporttelos-systems.comIP 2RU analog or AES-3 Web Browser Y Y N N N - 20kHz N N N Comrex Accesscomrex.comIP 1RU analog or AES-3 Web Browser N optional N N N BRIC HQ1, HQ2 15kHz Y Y Y Tieline IPtieline.comIP, optional ISDN, X.21/V.35, POTS, GSM 1RU and 2RU analog and AES-3 Front Panel, USB, Web Browser, RJ-45 Layer 2 N Y Y N Tieline Voice, Tieline Music, Tieline Music Plus, Raw Audio 23kHz Y Y Y

Irwin is the chief engineer of WKTU-FM, New York City.

Previous 1 2