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.