3 ms·

Can't help but think "jesus, not another protocol I have to support". People bitch and moan about SIP but the goddamn thing works and is already extensible if y

by Paul_S 12y ago

Can't help but think "jesus, not another protocol I have to support". People bitch and moan about SIP but the goddamn thing works and is already extensible if you need your own unique features. Can't you build on that? Instead you're like phone manufacturers who each come up with their own protocol because hey, we've got those sweet PBX boxes to sell too! I love your goal, but I really can't see why you can't use SIP to communicate and play nice with other endpoints out there. Surely that would be an advantage.

oddvar 12y ago
That would be one way to do it :) Problems with SIP: * There are so multiple SIP standards (e.g. rfc 3261 vs rfc 2543) * It doesn't support NAT (unless you do rfc5626, rfc5627 and ICE) * Its support for ICE doesn't work well with webrtc which dynamically generates candidates * SIP's reliability is bad unless you implement rfc3262 * We want to do messaging really well - and SIP's support for that is rather basic edit: finally, I do agree with your "yet another standard" comment! (as per the xkcd in http://matrix.org/blog/2014/09/03/hello-world/ http://matrix.org/blog/2014/09/03/hello-world/) Given that XMPP hasn't taken off as it could have done - and the fact that each large IM or VoIP application seems to end up writing their own version (and putting that in their own walled garden) - we think a new, well-defined open standard, together with open source reference server and client codebases can be the catalyst to create an interoperable and federated "message transport" solution for a multitude of services!
- deleted 12y ago
  [deleted]
ara4n 12y ago
So, for context: we ended up writing Matrix after literally 10 years of building SIP infrastructure, so we have some experience in SIP (and XMPP's) shortcomings :) The short answer to "why not extend SIP" is that SIP stacks are fairly fiddly to write and get right; and SIP/SIMPLE/MSRP is typically a lot more verbose and convoluted than HTTP (and hugely more verbose than SPDY and HTTP/2.0). There's no support in SIP for distributed storage of state, and there's no support for paginating and storing conversation history at all. In fact, some of the SIP community has even ended up bolting on IMAP(!) for storing conversation and call history :S Meanwhile, given HTTP is pretty simple and completely ubiquitous, so why bother with an alternative stack at all? In terms of "jesus, not another protocol I have to support" - I completely sympathise, hence quoting http://xkcd.com/927/ http://xkcd.com/927/ in my blog post... We didn't do this lightly :) One way of thinking of this is that right now you have LOADS of HTTP APIs out there for messaging - Twitter, FB, http://api.ihackernews.com http://api.ihackernews.com, Reddit... they're sufficiently easy to implement that every new site goes and builds a new one, and developers have to go and learn each new one every time. Meanwhile, none of them will ever federate or interoperate - the whole thing's totally fragmented. So whilst Matrix is indeed yet another API to support - hopefully it's one that might actually help solve this problem... so that the next time that someone wants to add a messaging HTTP API to their site, they can follow an interoperable pattern rather than reinvent the wheel again. Perhaps a better way of describing Matrix is "two-way RSS for arbitrary data, with distributed history" Does this help justify things at all? (Disclaimer: Matrix is all my fault)

by Paul_S 12y ago

oddvar 12y ago

That would be one way to do it :) Problems with SIP: * There are so multiple SIP standards (e.g. rfc 3261 vs rfc 2543) * It doesn't support NAT (unless you do rfc5626, rfc5627 and ICE) * Its support for ICE doesn't work well with webrtc which dynamically generates candidates * SIP's reliability is bad unless you implement rfc3262 * We want to do messaging really well - and SIP's support for that is rather basic edit: finally, I do agree with your "yet another standard" comment! (as per the xkcd in http://matrix.org/blog/2014/09/03/hello-world/ http://matrix.org/blog/2014/09/03/hello-world/) Given that XMPP hasn't taken off as it could have done - and the fact that each large IM or VoIP application seems to end up writing their own version (and putting that in their own walled garden) - we think a new, well-defined open standard, together with open source reference server and client codebases can be the catalyst to create an interoperable and federated "message transport" solution for a multitude of services!

deleted 12y ago
[deleted]

ara4n 12y ago

So, for context: we ended up writing Matrix after literally 10 years of building SIP infrastructure, so we have some experience in SIP (and XMPP's) shortcomings :) The short answer to "why not extend SIP" is that SIP stacks are fairly fiddly to write and get right; and SIP/SIMPLE/MSRP is typically a lot more verbose and convoluted than HTTP (and hugely more verbose than SPDY and HTTP/2.0). There's no support in SIP for distributed storage of state, and there's no support for paginating and storing conversation history at all. In fact, some of the SIP community has even ended up bolting on IMAP(!) for storing conversation and call history :S Meanwhile, given HTTP is pretty simple and completely ubiquitous, so why bother with an alternative stack at all? In terms of "jesus, not another protocol I have to support" - I completely sympathise, hence quoting http://xkcd.com/927/ http://xkcd.com/927/ in my blog post... We didn't do this lightly :) One way of thinking of this is that right now you have LOADS of HTTP APIs out there for messaging - Twitter, FB, http://api.ihackernews.com http://api.ihackernews.com, Reddit... they're sufficiently easy to implement that every new site goes and builds a new one, and developers have to go and learn each new one every time. Meanwhile, none of them will ever federate or interoperate - the whole thing's totally fragmented. So whilst Matrix is indeed yet another API to support - hopefully it's one that might actually help solve this problem... so that the next time that someone wants to add a messaging HTTP API to their site, they can follow an interoperable pattern rather than reinvent the wheel again. Perhaps a better way of describing Matrix is "two-way RSS for arbitrary data, with distributed history" Does this help justify things at all? (Disclaimer: Matrix is all my fault)