[In a former life, Director of SWE for Call/Media Processing at a large SIP consumer service provider.] From our standpoint, Bellhead vs. Nethead was very obvi

[In a former life, Director of SWE for Call/Media Processing at a large SIP consumer service provider.] From our standpoint, Bellhead vs. Nethead was very obvious. But it was also pretty obvious that the Netheads were driven by a eglitarian, idealistic dream that nobody actually wanted. LECs were the old, fossilized enemy with ponderous protocols driven by processing constraints that no longer existed. A system to track phone number assignments. Another system to track where calls to those numbers should be directed. A system for authenticating outgoing calls. A system for authenticating incoming calls. A system for call control. A system for media control. A system for actually transmitting the media. System, system, system. All good ideas once upon a time, but driven by long-gone resource contraints and most importantly by incremental layering. (Think USB-C x1000.) On the other hand, the Netheads dreamed of a completely decentralized network. No evil central power controlling a customer and limiting his power. Customers would directly plug endpoints into the Internet, and anyone could directly call anyone. Maybe some common directories, but even less centralized than DNS. NAT? Never. The result was a system that is in some ways just as complicated as the the bad-old telcos. Per SIP, no one player really has a complete view of the state of a call. It's smeared out between the caller endpoint, the callee, gateways, proxies, registrars. Most of SIPs complexity is in the negotiations between all the parties, detecting inconsistant views, and re-converging. Most of our software headaches were from needing to cajole hardware (much of which we controlled!) to pretty please do what was wanted. For example: there is a SIP "Best Current Practice" to park a call. It requires a special-purpose service endpoint to merely hold onto the call. The call-control flow diagram for it is... bloated. [1] In reality, customers didn't want unfettered access to their phones across the Internet. They wanted a centralized service provider who (a) held multiple users and devices under an "account" umbrella, and knew how it was configured ("I want both my phones to be do-not-disturb."), (b) knew global state ("Someone's on phone 1, roll it over to phone 2."), (c) performed verification and filtering of incoming calls ("Oh, that's Alice at internal ext. 251", "What! My local hospital is calling??!!"), (d) served as a shielding proxy (don't tell them my IP). And (e), especially (e) "I just want to plug the blasted box in and have it work. I'm not a phone administrator." As an implementor, what I really wanted for us-to-customer was a simple "make phone ring", "phone wants to call", "send media", "receive media", and "receive button pushes". For us-to-trunk it would be "initiate call leg", "receive call leg", and send/receive media. Nowadays, audio media would just be Opus. Ah well, I could wish... [1] RFC 5359 "Session Initiation Protocol Service Examples", secs. 2.15 & 2.16 https://www.rfc-editor.org/rfc/rfc5359.html#section-2.15 https://www.rfc-editor.org/rfc/rfc5359.html#section-2.15