The charitable interpretation is that the point is to let people know that there are several ways to do something similar, and there are off-the-shelf modules that can be used to accomplish it, if you don't want to use a browser. (The less charitable, but understandable interpretation probably runs along the lines of, "we've been doing this for a decade and it's frustrating that we haven't gotten enough recognition for it, to the point that the subject of this HN post seems to be striking people as quite unlike anything others have done before".)

> and "isn't an especially intelligible formulation"?

I think that's just typical nerd pedantry. As someone who has worked in this space (I co-built the WebRTC bits of Twilio's browser voice product back in 2012, including building a server-side implementation of WebRTC when none existed [at least not in a form we could use], and bridged that to our internal SIP-based voice infrastructure), I'm vaguely sympathetic to the desire for precision. It is correct to say that you can't bridge "WebRTC" to "SIP"; as I'm sure you know after the work you've done, WebRTC is a RTP-based media stack mated with STUN/TURN that happens to use SDP to describe voice/video sessions, while SIP is a signaling protocol that doesn't really specify anything about media.

I'm not sure I'd agree that most developers and customers use the language you assert, but admittedly I've been out of that space for a good 7 years at this point. Regardless, I think it's valuable to understand -- for perhaps the hypothetical someone new coming into the space that you bring up -- what WebRTC and SIP actually are, and that you can even use SIP to set up WebRTC sessions without any sort of bridging to other infrastructure.

I think that's a fair digestion of the force behind the tenor of my comment, which I would otherwise agree is perhaps a bit harsh.

> I think that's just typical nerd pedantry [...] It is correct to say that you can't bridge "WebRTC" to "SIP"

It's a bit ironic to me because I come from a humanities background, leading to amusing - and sometimes infuriating - cultural clashes with nerds and their pedantry, since I'm very comfortable gesturing at commonsensical understandings of things and being what programmers would consider "vague". I often grouse about needless nerd pedantry myself.

Nevertheless, telecom is about rigourous and labouriously articulated standards, and always has been. I think you correctly discern a note of displeasure in the way that people with this kind of metaphysic see the socialisation of RTC technology into the web economy. It's a bit like how Node is seen by classical systems programmers to be a psy-op meant to convince JS UI developers that they can write robust backend code. It does the job well enough, but sometimes you have to actually know things.

Yes, in short, I think that conflating "WebRTC" and "SIP" in this manner, and popularising this crude understanding of the various parts and where they fit, does not so much further productive adoption and public understanding as hinder it. In the case of RTC in particular, where tolerances are lower and robustness is paramount, taking the shortest path to democratisation of the most general QuickStart Guide may not be the best thing to do. We see the consequences of this every day on the mailing lists of the various open-source building blocks previously mentioned, as well as others, like JsSIP and SIP.js.