The hardest part is getting the signaling to work correctly over the internet (STUN/TURN/etc), which is why we advertise Tuber as only working on LANs. We tried to get some non-profit funding to finish that part up to no avail. I wonder how Hublin solved that problem?
I am really glad to see one of these finally go fully open-source. It has been stupid to see conferencing app after conferencing app only available through a hosted website. How are you supposed to deprecate expensive, proprietary enterprise videochat platforms if you can't deploy behind a firewall!?
ps. our logo is better than yours heh: https://blog.trailofbits.com/2015/12/15/self-hosted-video-ch...
Alternatively, we could purchase a ~$200 elgato HDMI capture box, and create a free youtube account to stream 60FPS 1080p across the planet.
Currently there is no in between for high FPS video streaming systems on the internet.
There's also https://jitsi.org/ and https://obsproject.com/ , but they don't seem to allow P2P connections with buffering options. The trade off for low/unreliable bandwidth is allowing larger buffers which would impose greater latency.
> Video chat systems/protocols look to be somewhat stagnate/immature
Eh. There's a lot of work being done with WebRTC, but I'm not going to say that's significantly advancing the state of the art with respect to video transport -- SDP, RTP, DTLS have all coexisted for a long time.
What has happened, though, is that by abstracting away media handling, the traditional "control plane" is being disintermediated. As a result, we're seeing 1) a lot of reinventing the wheel, and 2) more siloing among service providers. Both lead to feature fragmentation among providers and slows the progress of video-based services.
While I'll be the first to admit that SIP (and XMPP and H.323 and BFCP and ...) is rather too involved to be used outside a fully federated telecom environment, it's a bit of a shame that a nicer signaling protocol hasn't really gained any traction in in its stead. Having most services work from a higher level baseline could reduce feature fragmentation and speed up the perceived progress of video services. And hopefully encourage more interoperability, but that's probably a lost cause...
 I'm aware there are encoders that cost in that range, eg VBrick, and it's crazy -- you don't need to spend that much for video conferencing.
Your two examples are not equivalent at all.
The trade off for low/unreliable bandwidth is allowing
larger buffers which would impose greater latency
And this can't be done with any of the current clients based on webrtc, such as Hublin?
I have Skype running as a separate application and I have it's icon in the Dock and I can switch to it, it runs in the background, etc.
I know that this is the tool responsible for my communication.
My contacts are also running it and it usually starts automatically on their system so most probably they're online.
A conference tool running inside the browser doesn't have these properties. I look at it as a website which I can visit or not.
This, I guess is a problem with all WebRTC implementations out there - it might be great in terms of capabilities, but it's not very practical in terms of heavy daily usage.
These tools are great if you want to organise something like several people from Slack, Skype and email (customers).
It scaled well - hundreds of different conference participants per server node; media nodes that supported hundreds of simultaneous streams. Stream switching was on the order of scores of milliseconds (not seconds like all the webrtc stuff).
We had a port to Android for a little while. Then a Wine version. But the native Linux one was an orphan.
How is it doing this? Is each peer sending video to all the other peers? (I.e., with 3 users, each user has two outgoing and two incoming streams?)
Good question. Until now, with WebRTC, you always needed a STUN, TURN and signaling server . And I would be very surprised if they somehow managed to create a whole new architecture. It certainly seems like these servers are run centrally by Hublin.
Kind of like those remote help desk apps: I want to send a link and have them sharing their screen with me, no fuss.
I wonder how long before a FOSS self-hosted solution is available?
What I couldn't figure out from http://hubl.in though; how is Linagora going to cover the costs of (and presumably raise a profit from) this service? Is it a freemium model, or is the current phase simply intended to garner interest and gain a foothold in the market?
Issuer: Gandi Standard SSL CA 2
Expires on: 2017/03/06
Current date: 2016/03/16
Does anyone know whether WebRTC is used in HipChat and Slack video feature?
Hello doesn't have full screensharing, only browser content can be shared, which is a huge limitation.
Had a quick chat with another user, works fine for this limited tryout at least.
I like that adoption is not such a problem as you only have to share a link.