4 ms·

This is a really good read. My team has been implementing VoIP/IM protocols since around 2003, and we started off with H.323, then ISUP/PRI then H.324, then (br

This is a really good read. My team has been implementing VoIP/IM protocols since around 2003, and we started off with H.323, then ISUP/PRI then H.324, then (briefly) IAX, then SIP, then IMS, then RCS, then added XMPP, and then decided to start afresh and we created Matrix in 2014. 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. Stuff like E2EE barely exists at all. From our perspective, SIP monumentally failed: it had an incredible opportunity to create an open decentralised communication layer for the internet using "nethead-friendly" culture... but all it did was reinvent the semantics of the PSTN across private federations. Meanwhile, the actual communication semantics that people expect today (and for the last ~10 years) don't resemble the PSTN at all: they expect synchronised conversation history across multiple devices; typing notifications; read receipts; presence; file transfer; multiway video conferencing; stickers; reactions; E2EE etc. etc. In other words, they want the iMessage/Facetime/WhatsApp/Slack/Discord/Teams/Telegram featureset - they do not want something that pretends to be a 1890s vintage candlestick telephone. So this is why Matrix attempts to provide a nethead-friendly open standard for the featureset that users expect for communication these days: i.e. conversation history synchronised between devices; E2EE; group conversations as a first class citizen; and we even provide an open standard (possibly the first one?) for multiparty voice/video calls: https://github.com/matrix-org/matrix-spec-proposals/blob/SimonBrandner/msc/sfu/proposals/3898-sfu.md https://github.com/matrix-org/matrix-spec-proposals/blob/Sim.... Hopefully the story does not end with SIP(!) :)

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.

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.