4 ms·
> The really frustrating thing was how SIP just mimics the 1:1 circuit switched calling semantics of the old PSTN. Stuff like messaging and group-calling and gr
by MattJ100 4y ago
> The really frustrating thing was how SIP just mimics the 1:1 circuit switched calling semantics of the old PSTN. Stuff like messaging and group-calling and group-conversations is bolted on badly.
Yeah, I remember the period when XMPP was unsuccessfully trying to grow audio/video extensions (eventually fixed by Google's contribution of their Jingle efforts). Meanwhile the SIP ecosystem was unsuccessfully trying to grow messaging features. The two worlds (messaging and telephony) were for a long time like oil and water.
I'm glad those days seem to be behind us, though the tendency towards a WebRTC monoculture (which in turn descends from Jingle) does concern me a bit.
> (possibly the first one?) for multiparty voice/video calls
The protocol for multi-party Jingle was specified by the Jitsi team back in 2011: https://xmpp.org/extensions/xep-0298.html https://xmpp.org/extensions/xep-0298.html
This is still the foundation of the protocol that Jitsi uses today, I believe.
- Arathorn 4y ago> The protocol for multi-party Jingle was specified by the Jitsi team back in 2011: oops, I stand corrected. I don’t think I’ve ever seen a heterogenous XMPP conference call though (eg a Jitsi call but with participants using entirely different conferencing clients from different vendors?) Whereas MSC3401 and MSC3898 is implemented by Element call, Hydrogen, Third Room, maybe nheko, and maybe some proprietary Matrix clients now - and folks regularly mix & match clients (eg voice-calling into a Third Room world). Eitherway, it’s cool that the jitsi folks standardised their signalling. Last I checked with them they seemed to be all about “URL based calling”, and less about supporting interoperability with other clients.