It's also interesting that the precedence concept was in the original IP header RFC 791. https://datatracker.ietf.org/doc/html/rfc791#page-12 Probably a good thing it was dropped along the way or I can only imagine what Comcast would have done with that.
> Probably a good thing it was dropped along the way or I can only imagine what Comcast would have done with that.
You think you're joking.
ToS morphed into DSCP [1], which is sometimes used in residential networks to prioritize VoIP. (I can't speak to business or industrial networks; presumably it finds use there as well.) WLAN networks can be configured to heed this priority, more aggressively grabbing airtime for high-priority packets. I configure my home network that way.
DSCP does not generally cross the home network<->Internet boundary, but there is one major exception I know of: Comcast. They tag all non-CATV traffic as the lowest priority (DSCP 8), resulting in terrible performance of any home network configured to heed DSCP values. (You can avoid this by stripping DSCP values from inbound packets.)
Hah, I wish I'd remembered that when I wrote this post. There's a whole story about IP having borrowed concepts from AUTODIN and AUTOVON as well as computer precedents like NCP. Of course the idea that DoD would move their networks over to IP was actually surprisingly unsuccessful and to this day a lot of the originally envisioned concepts like multilevel security on IP networks are no closer to happening.
In parallel, most modern military/IC telephone systems are commodity Cisco with specialty features added somewhat awkwardly. Not nearly as exciting as it once was.
The precedence system is added to some VoIP networks as a line appearance feature although I suspect that's just being implemented by adding the prefixes to the dial plan, so it's the same as most of the other post-DTMF networks. You could do the same on your own system if you wanted, most IP PBXs support the actual underlying trunk preemption features but they just aren't typically configured to be accessible to users (more for things like allowing trunk preemption for emergency calls).
The bigger issue is TEMPEST and other COMSEC concerns, which lead the government to pay companies like CIS to perform an authorized aftermarket modification of off-the-shelf IP phones.
A major issue is that NSA guidance requires that all telephone instruments in a secure area have a feature usually called "on hook protection" or "on hook security," where the phone physically being on the hook switch electromechanically ensures that microphones are disabled. This was easy with many earlier phones because they were often physically wired this way (hook switch connected the voice circuit). For modern IP phones this is all software controlled, so for secure variants like those made by CIS some dedicated electronics have been added that disconnect the microphones until the user presses a physical button to enable them. This is outside of software control to prevent a network intrusion being able to use the phone as a listening device. The modification is usually somewhat clunky and you can regularly recognize it in photos from military, white house, etc environments due to the Cisco phone's awkward looking and unusually large rear enclosure (added RF shielding against emissions) and a small red button added via a hole drilled in the faceplate, once again awkwardly.
I bring this up in detail because I find it very interesting that the government has chosen to pay a third party to modify a COTS product in this way when they used to just have the phones custom made. I'm sure it's more cost effective but seems like a surprising failure by e.g. Raytheon, who used to make several secure phones, to win the contract. It's probably also a factor that there are nowadays a surprisingly large number of independent secure telephone systems operated by different agencies, which has diluted the buying power somewhat. The days when it was DoD making central purchasing decisions are gone, these days much of secure telephony is in the intelligence community where despite efforts of the ODNI the level of standardization on secure networks is rather poor. There are some good reasons for this but there's also a lot of plain bureaucratic lockup.
electrospaces.net is the blog of a person interested in secure telephony who knows more about the actual instruments than I do. If you look through the archive he has photos of many current and historic models. I believe I have more information about the cryptographic and switching systems, which I do plan to write about, but there's only so much to know since the details of these things often start out classified and thus end up obscure. The historic military systems are much better documented than the IC systems, mostly because DoD and AT&T produced a lot more documentation on them that gets declassified as they go out of use. The IC likes to use a lot more suite A crypto (classified algorithms) and systems tend to be smaller and have shorter lifespans, which all leads to less stuff preserved for history.
The topic is interesting in general though, and I will probably write a future post about exotic government telephone technology like the STUs with Fortezza cards and the earlier Crypto Ignition Keys. These are honestly rather smart designs that never really made it to private industry.
Here are allegedly the guidance on what the precedence levels should be used for. http://www.plexoft.com/SBF/Autovon.html