Image courtesy of Tieline Technology
The way we carry out remote broadcasts hasn't really changed that much over the last 50 years — at least until recently. The introduction of ISDN codecs in the early 1990s was really the only substantial change during that time. If you wanted to do a remote, you either a) got a phone line, or b) used your own semi-private (RPU) radio channel. The equipment has modernized over the years; but the point is that the resource you used was not shared. The phone line was yours and yours alone; you didn't need to worry that there would be another remote going on over it when you went to use it. ISDN is pretty much the same: when you dialed-out on it, and connected, those two B channels are all yours.
Consider the nature of the Public Switched Telephone Network: For many years it was strictly done on a TDM basis. Your DS0 was all yours (at least till you hung up).
Several methods of wireless remotes are available, such as a Comrex Access portable unit with Verizon EVDO card.
But time and technology have moved on. Ethernet became common around radio stations in the early 1990s, and the Internet really came into common use in radio around the mid 1990s. The idea that users would have their own, unshared data connections has become obsolete (even though it is still in common use). Phone lines and ISDN are still frequently used for the execution of remote broadcasts, but the shared-use nature of the Internet is finally making inroads in that particular aspect of broadcasting.
Along with the obvious advantages of using the now-ubiquitous Internet for remotes come certain issues (I hesitate to call them disadvantages) that need to be addressed.
Internet access is everywhere
An APT Worldcast Eclipse built in to a remote kit.
As I said, the Internet is ubiquitous; you find it in every office with a computer — and when was the last time you saw an office that didn't have a computer? But in places that we do remotes — whether it's a sports bar, a nightclub or the county fair, common access to the Internet is still fairly new. It's become so easy now. Broadband access is common; you can buy Ethernet switches all around town; and you can buy CAT-5 and an RJ-45 crimper at the local hardware store. This is the obvious advantage to using the public Internet. How many times (in the old days) did you wait to hear back from the telephone company to see if a line could be dropped in to the proposed remote location? Or, if you use RPU, how many times did you find the signal out of the remote site was OK but maybe slightly noisy?
But using the public Internet gets a little more difficult after you get past the fact that it's already there and in place for you. The shared nature of the Internet doesn't easily lend itself to the sort of continuous, high-rate data output that would be easily accommodated by ISDN or a telephone line. When a user receives documents on the Internet — such as a webpage, or a photo — errors in transmission are easily overcome and likely not even noticed. Lost packets, for example, can be retransmitted. Late packets just slow the download a little.
Figure 1: In a packet-switched model, connections to the Internet Service Provider are shared among all hosts, and all Internet traffic from hosts A through n are shared through the connection between the Internet and the router/firewall.
Click to enlarge
Another issue regarding the use of the public Internet is a little more subtle. As you sit in your office or workspace everyday and use the Internet, you are originating a connection from the private side of your network to the public side of your network via a router and firewall. When a website (for example) sends a message back to you, your router/firewall is expecting it, knows it's for you, and lets it through back to your host computer. But, if you try to originate a connection from outside of your firewall on the public Internet, with the idea that you will communicate with a host on the private side of your network, all bets are off. Unless the firewall is specifically configured to allow this to happen, it won't work. After all, that's the firewall's job — to prevent intrusion. As far as it is concerned, the attempt to communicate from outside the network is just that.
Internet data transmission problems
So let's take a look into how these problems are addressed. First, it makes sense when contending with other users for bandwidth in a system that has a limited amount available that there is an advantage in minimizing one's 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, codecs that work over synchronous networks (like ISDN or TDM).
Figure 2: After the connection is made (Nailed-VP), the two bearer channels (64kb/s each, duplex) and the data channel (16kb/s) are dedicated strictly to the user for the duration of the call.
Click to enlarge
The packet-switched nature of the Internet (as opposed to the circuit-switched, TDM nature of the PSTN) complicates the situation considerably though. The data stream that represents the audio output of the encoder is made up of frames, which are strings of data that comprise the payload data bits, overhead data bits, and of course timing. These frames are subsequently assembled into packets (or datagrams) and each packet has additional information (source and destination IP addresses for example) appended to it prior to its injection into the network. That packet overhead is the same on a per-packet basis; so one can see that by changing the packet size (by adding more frames) one affects that overall bandwidth needed to move the packets.
An unfortunate characteristic of the Internet is that sometimes these packets are lost along the way, for various reasons. Ideally the packet size should be large because the overall bandwidth requirement is reduced. However, if one of those large packets is lost, then a substantial amount of the audio encoder data will be missing at the far end. 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 that the best compromise between packet size and overall bandwidth can be met.
If a broadband Internet connection is available, IP codecs make last-minute remotes a simpler possibility. Image courtesy of Tieline Technology
Inevitably, some packets will still be lost though, and there are other mechanisms designed to further minimize the negative effects. 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 possible 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.
The nature of the Internet also results in packets sometimes arriving late at the receive end 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 to be something that isn't good when doing remotes. Therefore, once again, one must strike a compromise between problems in the audio caused by late or out of sequence packets, and the amount of delay one can deal with at the remote site.
To review, let's 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 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.
So the problems I've just discussed are ones taken on and solved by the equipment designers themselves. Now let's go in to some of the issues you'll experience as a user of this type of equipment. They're all related to network security.
At your studio headquarters, likely you'll have a rack-mounted version of the IP codec you've chosen. Obviously it will need a network connection and access to the public Internet. Assuming you originate your remote broadcasts from the field, your HQ device will need to be able to be contacted from the public Internet. This presents a big problem to most network administrators because it is often against company IT policy to allow uncommon ports to be open on the router or firewall. (More on the topic of ports below.) For this reason, the HQ unit will not be able to work on your company LAN.
One way around this (and there is more than one) is to put the HQ unit on its own network. As I wrote earlier, broadband access is common now: you can look into the installation of a DSL line in to your facility, or alternatively, if cable TV is available, a cable modem. Hang the HQ codec on this mini-LAN, and it will be easily accessible from the outside.
Another way to get around this security issue is by way of a proxy server. This proxy server is located outside of your network, and a connection is made to it from your HQ codec via the public Internet. A session is initiated by your HQ codec, and the proxy server records the IP address of your codec and actually maintains a connection with it thereafter. From the field, then, you connect to the proxy server, and it in turn redirects the packets to your studio codec through the connection that it has maintained.
The issue of connecting to the public Internet with the portable IP codec is a little more complex though. I've used three different methods. The obvious one is to jump on a LAN that already exists. As I wrote earlier, many venues have some sort of network in place now, usually by way of a broadband connection of some sort: DSL or cable. If they have a router attached to it (likely) then you have to deal with the same network security issues that I also mentioned earlier. In this case, you'll have to have access to the router itself, so you can configure it for port-forwarding.
Let's talk about port-forwarding. One aspect of the common broadband connection you find is that it has one IP address on the Internet. The router is able to accommodate multiple host computers on its private side even while only having one public Internet address by way of network address translation. When a host computer on the private side runs an application that needs access through the router out to the Internet, that application will have an associated port number. The router makes note of this port number; and so when it later receives messages from the Internet that include a particular port number, it knows to use that port number in sending that received information back to the correct host computer on its private side. Since these small routers are used to give small offices Internet connectivity, the port associated with http is by default, open. However, when you want to add an uncommon application to the private side (like your Internet codec) you will need to configure the router to have the necessary ports open so the traffic will be allowed to pass in both directions.
If you can get the credentials to log in to the router's administrative console (done via its LAN) you can generally make the necessary changes. (If you have a good relationship with the venue owner, he will hopefully give you the credentials or he'll have his own administrator do the configuration for you.) I'm generalizing here, but once you log in to the particular router, you will be able to find the page for port-forwarding. Two pieces of information are needed: first are the necessary port numbers, which you will get from the specific equipment documentation. Second will be the IP address of the codec itself when on the LAN in question. When configuring the port-forwarding, you are basically telling the router to allow packets for applications that correspond to the port number you have programmed to pass through to the IP address you have also programmed. That's it in a nutshell.
In many instances, the router attached to a broadband Internet connection at a venue will have Wi-fi capability. You'll need to go through the port-forwarding process whether you use a wired or wireless connection. You'll also likely need credentials to be able to log on to the Wi-fi access point. Get those from the network admin, or look them up at the same time you set up the port forwarding.
The third means by which I've used a remote IP codec is by way of a plug-in EVDO card. This was certainly a very convenient way to go, and offered reasonably good service, though not as good as a network that was more under my control.
Once your IP codecs are talking end-to-end, you'll be doing a remote that is very much like any other, especially compared to ISDN. There will be some amount of delay going both directions, so it'll be necessary to develop a mix-minus at the studio. Depending upon the quality of your connection through the Internet, you may occasionally experience a drop-out or other odd audio quality related to traffic issues. My experience so far has been that these are brief, and parameters that can be adjusted to minimize the negative effects are adjusted inside the codecs without our notice.
Learning how to use IP codecs takes a little time and may require some patience on your part. Hopefully learning about new techniques is something you like to do. Using IP codecs for remotes has provided some excellent results for the group of stations I work for. Not only have we done the standard type of remote, but we've given our programming people a new tool as well, since we've now greatly expanded our capability, in terms of where we can do them, and their timeliness.
Irwin is transmission systems supervisor for Clear Channel NYC and chief engineer of WKTU, New York. Contact him at email@example.com.
+49 811 55 17 0
+44 121 256 0200
+44 1747 861123