5 ms·

WebRTC establishes p2p connection over which you can transfer media streams or other data via the data channels provided by the API. Using WebSockets you canno

by mgechev 12y ago

WebRTC establishes p2p connection over which you can transfer media streams or other data via the data channels provided by the API. Using WebSockets you cannot make two browsers communicate directly without using any proxy in the middle. So WebRTC has the following benefits: - establish p2p connection between two browsers (not necessary required to be browsers) - transfer media (audio/video) efficiently - allows data streaming over UDP/TCP/SCTP (you can use one, depending on your application type - for example UDP if you're looking for performance over reliability) And the following drawbacks: - requires more complex architecture (for the NAT traversal procedures via ICE) - you have no guarantee that the connection between the peers will be established (in case of symmetric NATs in front of the peers you want to connect) - has more complex API

johansch 12y ago
Regarding NAT: does it do anything to attempt to solve this problem, or is that entirely left to the app developer?
- mgechev 12y ago
  You can use TURN server in case of symmetric NATs. RTCPeerConnection can accept a list of TURN servers and fallback to them in case p2p connection cannot be established.
e12e 12y ago
This still doesn't really answer why one would use webrtc for multi-user video conferencing - without working multicast (which I still think is a given between most pairs of randomly choosen dsl subscribers, not sure if it would be an option for webrtc anyway) - you'd need to transfer N-1 bitrate up from each N participant in the multi-user conference. Not sure that's workable for ten 720p streams of reasonable quality - let alone for more participants? Clearly there are trade-offs - but do they make as much sense for multi-user conferencing? The teamspeak model of muxing streams on the server seem to make more sense? Edit: I see this is actually addressed in the linked article[1] - basically a webrtc gateway can be used. No mention of any support for (cryptographic) authentication and of peers and encryption of streams as far as I csn tell, though. Which makes it a bit worse than chatting over ham radio... Edit2: Apparently webrtc is "secure" by default [2] - that is the streams are encrypted with a session key - but there's no (working) way to authenticate - or prevent/detect mitm. Obviously a gateway would need access to the (plain) streams for muxing (barring some creative N-way p2p key setup and just blasting encrypted data (eg by not supporting more than one peer to transmit - but with typical latencies this would probably dictate some form of manual "passing-the-mic" moderation). [1] http://blog.mgechev.com/2014/12/26/multi-user-video-conference-webrtc-angularjs-yeoman/ http://blog.mgechev.com/2014/12/26/multi-user-video-conferen... [2] http://blog.erbbysam.com/?p=149 http://blog.erbbysam.com/?p=149
- EGreg 12y ago
  Having designed a decentralized social networking system, I have become firmly convinced that - unlike bitcoin - it actually helps to have a server for each conversstion, in order to both have efficiency in the network topology as well as much more easily implement things people har come to expect, such as fair message ordering and no client able to mess up the others in a conversation. Mental poker is possible but clients still need to trust each other. May as well designate one as a server then. The CAP theorem is likewise addressed by partitioning all the messages by conversation. There is little need for total consistency between conversations, only within them. If you want me to elaborate further, you have to email me because there's too much to say.
  - e12e 12y ago
    [Edit: never mind, I think I misread what you were saying - you're also advocating one "client"/participant to be on a dedicated "server" (aka daemon on a well-connected/always connected host? Leaving the rest as it might have some value either way for those considering conference solutions and topologies...] You're commenting on the parts about authentication? Because I don't see how setting up some dsl subscriber (or 4g mobile client) in (say) Japan is going to be very helpful in splitting two dozen 720p video streams across the global Internet for a modest multi-user video conference. Never mind the issues with the connection dropping for everyone if the designated "server" experience network (or other) issues..? The original Planetside game from SOE bundled TeamSpeak (which is not p2p, but client-through-central-gateway/server) - but the bundled version was pretty much unusable in part because it meant one player hosted the server. Worked fine with a dedicated TeamsSpeak server (eg on a vps etc). For many uses I can also see optional recording of conferences might be useful - but that could probaly be accommodated using a dedicated recording client (probably on a "server").

by mgechev 12y ago

johansch 12y ago

Regarding NAT: does it do anything to attempt to solve this problem, or is that entirely left to the app developer?

mgechev 12y ago
You can use TURN server in case of symmetric NATs. RTCPeerConnection can accept a list of TURN servers and fallback to them in case p2p connection cannot be established.

e12e 12y ago

This still doesn't really answer why one would use webrtc for multi-user video conferencing - without working multicast (which I still think is a given between most pairs of randomly choosen dsl subscribers, not sure if it would be an option for webrtc anyway) - you'd need to transfer N-1 bitrate up from each N participant in the multi-user conference. Not sure that's workable for ten 720p streams of reasonable quality - let alone for more participants? Clearly there are trade-offs - but do they make as much sense for multi-user conferencing? The teamspeak model of muxing streams on the server seem to make more sense? Edit: I see this is actually addressed in the linked article[1] - basically a webrtc gateway can be used. No mention of any support for (cryptographic) authentication and of peers and encryption of streams as far as I csn tell, though. Which makes it a bit worse than chatting over ham radio... Edit2: Apparently webrtc is "secure" by default [2] - that is the streams are encrypted with a session key - but there's no (working) way to authenticate - or prevent/detect mitm. Obviously a gateway would need access to the (plain) streams for muxing (barring some creative N-way p2p key setup and just blasting encrypted data (eg by not supporting more than one peer to transmit - but with typical latencies this would probably dictate some form of manual "passing-the-mic" moderation). [1] http://blog.mgechev.com/2014/12/26/multi-user-video-conference-webrtc-angularjs-yeoman/ http://blog.mgechev.com/2014/12/26/multi-user-video-conferen... [2] http://blog.erbbysam.com/?p=149 http://blog.erbbysam.com/?p=149

EGreg 12y ago
Having designed a decentralized social networking system, I have become firmly convinced that - unlike bitcoin - it actually helps to have a server for each conversstion, in order to both have efficiency in the network topology as well as much more easily implement things people har come to expect, such as fair message ordering and no client able to mess up the others in a conversation. Mental poker is possible but clients still need to trust each other. May as well designate one as a server then. The CAP theorem is likewise addressed by partitioning all the messages by conversation. There is little need for total consistency between conversations, only within them. If you want me to elaborate further, you have to email me because there's too much to say.
- e12e 12y ago
  [Edit: never mind, I think I misread what you were saying - you're also advocating one "client"/participant to be on a dedicated "server" (aka daemon on a well-connected/always connected host? Leaving the rest as it might have some value either way for those considering conference solutions and topologies...] You're commenting on the parts about authentication? Because I don't see how setting up some dsl subscriber (or 4g mobile client) in (say) Japan is going to be very helpful in splitting two dozen 720p video streams across the global Internet for a modest multi-user video conference. Never mind the issues with the connection dropping for everyone if the designated "server" experience network (or other) issues..? The original Planetside game from SOE bundled TeamSpeak (which is not p2p, but client-through-central-gateway/server) - but the bundled version was pretty much unusable in part because it meant one player hosted the server. Worked fine with a dedicated TeamsSpeak server (eg on a vps etc). For many uses I can also see optional recording of conferences might be useful - but that could probaly be accommodated using a dedicated recording client (probably on a "server").