On 05/15/2016 03:16 PM, Måns Nilsson wrote:
...If you think the IP implementations in IoT devices are naîve, wait
until you've seen what passes for broadcast quality network
engineering. Shoving digital audio samples in raw Ethernet frames is
at least 20 years old, but the last perhaps 5 years has seen some
progress in actually using IP to carry audio streams. (this is
close-to-realtime audio, not file transfers, btw.)
Close to realtime is a true statement. Using an IP STL
(studio-transmitter link) has enough latency that the announcer can no
longer use the air signal as a monitor.
And the security side of things is a pretty serious issue; just ask a
major IP STL appliance vendor about the recent hijacking of some of
their customers' IP STL devices.... yeah, a random intruder on the
internet hijacked several radio stations' IP STL's and began
broadcasting their content over the radio. Not pretty. I advise any of
my remaining broadcast clients that if they are going to an IP STL that
they put in a dedicated point to point IP link without publicly routable
IP addresses.
Digital audio for broadcast STL's is old tech; we were doing G.722/G.723
over switched-56 in the early 90's. But using a public-facing internet
connection with no firewalling for an IP STL appliance like the Barix
boxes and the Tieline boxes and similar? That borders on networking
malpractice.
... But, to try to return to "relevant for NANOG", there are actual
products requiring microsecond precision being sold. And used. And
we've found that those products don't have a very good holdover. ...
Television broadcast is another excellent example of timing needs; thanks.
Valdis mentioned the scariest thing.... the scariest thing I've seen
recently? Windows NT 3.5 being used for a transmitter control system,
within the past five years. I will agree with Valdis on the scary
aspects of the public safety communications Mel mentioned. Thanks, Mel,
for the educational post.
