4 ms·

> Has anyone got experience with both XMPP and SIP/H.323? I've worked with all three. The H.323 vs SIP battle was fought a long time ago... for better or worse

> Has anyone got experience with both XMPP and SIP/H.323? I've worked with all three. The H.323 vs SIP battle was fought a long time ago... for better or worse, SIP won. Any H.323 systems still in the wild can probably be considered "legacy." That being said, while H.323 has more "batteries included," its call flow is accordingly more complex. SIP is not too bad, there is some subtlety to it, but the main issue is that you have to piece together dozens of RFCs for an interoperable system, not to speak of implementation-specific quirks. XMPP is the more appropriate protocol in this context -- IM and group chat -- because it has had presence and ad-hoc messaging baked in from the start, including reasonably supported MUC. Ultimately, XMPP's issues are similar to SIP's -- the patchwork of XEPs is too unwieldy to work with. For an example, compare the multimedia bits (eg, Jingle) and the corresponding SIP session setup flow. The stigma of being a XML-based protocol designed in the 90's doesn't help, either. The biggest reason SIP is sticking around, however, is that it has major buy-in from the telcos with IMS/4G. However, SIP is also a more appropriate protocol for traditional telephony. In that respect, comparing SIP and XMPP is a bit like comparing apples to oranges. With the appropriate extensions, one could behave like the other, but it wouldn't be their strength.

fletchowns 11y ago
What are some of the reasons it's hard to design a good messaging protocol?
- jallmann 11y ago
  If you know your requirements up front, then it's not hard. In fact, it's a good exercise to do so -- probably one reason why messaging systems are a dime a dozen nowadays. What's hard is making a messaging system that is everything for everybody. If SIP or XMPP has taught us anything, it's that "extensibility" is a killer. Requirements evolve, and often it is perceived as easier or "cleaner" to start from scratch, rather than work around the idiosyncrasies of existing systems. On the other hand, if you are trying to design a protocol to solve a domain specific problem (eg, in cryptography, multimedia, distributed systems, etc) then it becomes more of a research endeavor with all the associated pitfalls. In that case, there will always be the "shoulders of giants" to build off of. Unfortunately though, for every pioneering TextSecure, there are a dozen CryptoCats repeating the same mistakes of years past...
e12e 11y ago
Sigh, sorry to hear that. I was hoping h.323 might work well for a personal call system with the option of ditching regular cell service. And just try and brute force most communication through h.323 :-/ It seems obvious multimedia calls is part of our future, and I refuse to let that be dictated by corporate lock-in -- be that Skype/Lync, Hangouts or whatever Facebook will launch when they enable videochat. And any videochat/conference needs text messaging/conversations too, so it seems like it would be nice to run everything through one server/service. Which I had hoped made sense would be a h.323 server (along with open source clients+maybe a websocket/web-client bridge). Guess it'll have to be SIP for phone (so I can ditch my regular cell service), maybe SIP for videochat (but I'm sceptical about the videoconferencing bit)... and XMPP for messaging. As neither Facebook, Google nor Microsoft support either XMPP in general (making it feasible to set up a bridge server) anymore, nor federation (which would actually be useful), I suppose I'll just have to give up on the idea that there'll appear a chat network where I'll be able to reach most of my contacts with a Free/Open client that isn't forced to play catchup to corporate whims. For a while, Facebook via XMPP worked (but not group chat), now it's back to sms. Which is annoying because sms is gated by the telcos, although it should be easy enough to make a xmpp<>sms gateway (eg: [s]) with a spare android phone. For personal use that wouldn't have to incur any sms fees (but would mean keeping a non-free cellular plan). For others frustrated by the same, there's at least a "traditional" project to reverse-engineer working with FBs current chat: https://github.com/jgeboski/bitlbee-facebook https://github.com/jgeboski/bitlbee-facebook [s] http://projectmaxs.org/homepage/ http://projectmaxs.org/homepage/ [ed: Forgot to commend duckduckgo and fastmail on hosting proper XMPP with federation and registration (at least ddg[d]) enabled. That's one reason why XMPP is nice -- you can actually point non-technical users at a suitable client, and add a couple of screenshots how how to set it up with ddg -- and they can then federate/talk away (that is assuming you don't/can't/won't support registration on your own server -- in my case the main reason not to recommend people wanting to talk to me to register on my server, is that I wouldn't know what kind of "SLA" my own server would have -- so if they used XMPP for other things than talking to me, having an account with someone a little more dedicated to keeping a server open to the general public might be better. But the main point is that that just works with XMPP today. And it should've just worked with both Facebook chat and Google talk/hangouts/newnamehere. And it probably also should've worked with Microsoft accounts/skype/hotmail. [d] https://duck.co/blog/post/2/using-pidgin-with-xmpp-jabber https://duck.co/blog/post/2/using-pidgin-with-xmpp-jabber ]

fletchowns 11y ago

What are some of the reasons it's hard to design a good messaging protocol?

jallmann 11y ago
If you know your requirements up front, then it's not hard. In fact, it's a good exercise to do so -- probably one reason why messaging systems are a dime a dozen nowadays. What's hard is making a messaging system that is everything for everybody. If SIP or XMPP has taught us anything, it's that "extensibility" is a killer. Requirements evolve, and often it is perceived as easier or "cleaner" to start from scratch, rather than work around the idiosyncrasies of existing systems. On the other hand, if you are trying to design a protocol to solve a domain specific problem (eg, in cryptography, multimedia, distributed systems, etc) then it becomes more of a research endeavor with all the associated pitfalls. In that case, there will always be the "shoulders of giants" to build off of. Unfortunately though, for every pioneering TextSecure, there are a dozen CryptoCats repeating the same mistakes of years past...

e12e 11y ago

Sigh, sorry to hear that. I was hoping h.323 might work well for a personal call system with the option of ditching regular cell service. And just try and brute force most communication through h.323 :-/ It seems obvious multimedia calls is part of our future, and I refuse to let that be dictated by corporate lock-in -- be that Skype/Lync, Hangouts or whatever Facebook will launch when they enable videochat. And any videochat/conference needs text messaging/conversations too, so it seems like it would be nice to run everything through one server/service. Which I had hoped made sense would be a h.323 server (along with open source clients+maybe a websocket/web-client bridge). Guess it'll have to be SIP for phone (so I can ditch my regular cell service), maybe SIP for videochat (but I'm sceptical about the videoconferencing bit)... and XMPP for messaging. As neither Facebook, Google nor Microsoft support either XMPP in general (making it feasible to set up a bridge server) anymore, nor federation (which would actually be useful), I suppose I'll just have to give up on the idea that there'll appear a chat network where I'll be able to reach most of my contacts with a Free/Open client that isn't forced to play catchup to corporate whims. For a while, Facebook via XMPP worked (but not group chat), now it's back to sms. Which is annoying because sms is gated by the telcos, although it should be easy enough to make a xmpp<>sms gateway (eg: [s]) with a spare android phone. For personal use that wouldn't have to incur any sms fees (but would mean keeping a non-free cellular plan). For others frustrated by the same, there's at least a "traditional" project to reverse-engineer working with FBs current chat: https://github.com/jgeboski/bitlbee-facebook https://github.com/jgeboski/bitlbee-facebook [s] http://projectmaxs.org/homepage/ http://projectmaxs.org/homepage/ [ed: Forgot to commend duckduckgo and fastmail on hosting proper XMPP with federation and registration (at least ddg[d]) enabled. That's one reason why XMPP is nice -- you can actually point non-technical users at a suitable client, and add a couple of screenshots how how to set it up with ddg -- and they can then federate/talk away (that is assuming you don't/can't/won't support registration on your own server -- in my case the main reason not to recommend people wanting to talk to me to register on my server, is that I wouldn't know what kind of "SLA" my own server would have -- so if they used XMPP for other things than talking to me, having an account with someone a little more dedicated to keeping a server open to the general public might be better. But the main point is that that just works with XMPP today. And it should've just worked with both Facebook chat and Google talk/hangouts/newnamehere. And it probably also should've worked with Microsoft accounts/skype/hotmail. [d] https://duck.co/blog/post/2/using-pidgin-with-xmpp-jabber https://duck.co/blog/post/2/using-pidgin-with-xmpp-jabber ]