IP remotes: Instantly Practical
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).
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.
Acceptable Use Policy blog comments powered by Disqus
[an error occurred while processing this directive]
Today in Radio History
The history of radio broadcasting extends beyond the work of a few famous inventors.
EAS Information More on EAS
The feed provides feeds for all US states and territories.
Need a calendar for your computer desktop? Use one of ours.
Information from manufacturers and associations about industry news, products, technology and business announcements.
This high-visibility and high-traffic area got the full acoustic treatment.
Browse Back Issues[an error occurred while processing this directive]
Also in the May Issue
- Remote Access and Site Connectivity: Wireless
- Standards of FM Allocation and Interference
- Side by Side: Mic Processors
- Field Report: Deva Broadcast DB4004
- Field Report: APT WorldCast Systems Horizon NextGen
- New Products
- 20 Years of Radio magazine: May 1994