3 ms·

Yes, that is the "full mesh" that I mention in my comment... This platform - and jitsi/janus/zoom/whatever - all use an SFU for more than a handful of particip

Yes, that is the "full mesh" that I mention in my comment... This platform - and jitsi/janus/zoom/whatever - all use an SFU for more than a handful of participants.

fulafel 7y ago
But thats very doable. And no need for the unaccelerated ffmpeg wasm afaics, and no need to use a "sfu". I don't know what Mediasoup does, was just commenting on what webrtc can do re the "the current state of webrtc" subject.
- supermatt 7y ago
  Do you have any examples of a webrtc video conferencing platform that provides a sufficient user experience over full mesh with 4 or more participants on disparate internet connections? Im just saying that this library (and similar platforms) ARE the cutting edge of webrtc. At small number of participants, they use full mesh (which is e2ee), but at larger scale, they need to use an SFU (which is not e2ee without jumping through some crazy hoops - but this is being worked on)
  - fulafel 7y ago
    No (but i hope they exist, havent looked) - however not all webrtc apps are general videoconf platforms. You don't even need servers if you go full p2p.
    - supermatt 7y ago
      You still need servers to handle the signalling, perform ICE and TURN where applicable.
      - fulafel 7y ago
        Only if you need to support users without full internet connectivity. Again webrtc can be used in many different requirement contexts.
        supermatt 7y ago
        You can certainly manually handle the signalling to set up the offer/answer. e.g. read them out to your peer(s). You would still need some form of STUN server (but there are a number of 'freely accessible' ones, even configured as defaults in some browsers) to get your reachable address/port/proto. You cant, AFAIK, handle this manually - it is handled internally as part of ICE. Then you would need to manually handle the signalling of these as well. Thats the bare minimum you have to do to peer over webrtc under ideal circumstances, but its certainly doable. So you do that for each peer. If you (or a peer) change streams you will do the same thing all over again
        fulafel 7y ago
        STUN is not needed if the participants have full internet connectivity, only if you have to work around NAT.
        supermatt 7y ago
        As mentioned, you cant manually set up your listening ports - this is handled internally by ICE, which needs to connect to a STUN server to get (at a minimum) your public IP address. edit: cant reply to your comment fulafel, but on that project you posted: https://github.com/cjb/serverless-webrtc/blob/master/serverless-webrtc.js#L25 https://github.com/cjb/serverless-webrtc/blob/master/serverl... Also, note that even if this wasnt defined, some browsers contain defaults. You 100% need STUN, but you can handle the signalling manually - as I stated. edit2: cant reply to your comment ibc, but I was explaining the bare minimum 'serverless' webrtc case still required a STUN server. I appreciate that mediasoup SFU uses ice-lite instead.
        fulafel 7y ago
    - ibc 7y ago
      mediasoup co-author here. > You don't even need servers if you go full p2p If you have N participants into the same "room", and do not have a central SFU that relays streams to others, then you have a full mesh network with all participants sending audio and video to all the others. Is that the "go full p2p" you meant?. Well, try it, and you'll see how your CPU burns when the browser/app tries to encode your webcam video source N times. And of course, you'd need N x uplink.
- ibc 7y ago
  mediasoup co-author here. So you don't know what mediasoup does but you assure that "no need to use a SFU". Too much free time to comment maybe? e2ee makes sense in one-to-one and N-to-N scenarios. It's just more complex in N-to-N scenarios because you DO need a centralized server so each participant just sends its audio/video once (to the server) and the server distributes it to others given whichever application policy/logic. That's a SFU, and that's what mediasoup does.
  - fulafel 7y ago
    We may be talking past each other, I'm talking about webrtc in general as the subthread was discussinh that. Think about a limited user count screen sharing or vr app with a/v comms built in for example.
    - ibc 7y ago
      I thought this news was about mediasoup, not about WebRTC in general. Said that I agree that your scenario is valid without any media server.
kabes 7y ago
For some reason I can't reply to fulafel. But a full mesh is definitely not very doable when you're dealing with a larger amount of people. Close to all conferencing solutions today are working via an SFU for a reason. E2E encryption via the SFU gets more and more attention and is being worked into the spec. But it can't be counted as state of the art in webRTC today
- fulafel 7y ago
  Most calls are not between large amount of people, a portion of webrtc applications would rather compromise on particiant # than security.
  - supermatt 7y ago
    For small numbers of participants, many of these platforms use full mesh (which is e2e encrypted).
    - fulafel 7y ago
      Yep, but you can't trust that e2e is a property of the app then, unless it prominently features in the ui.
      - supermatt 7y ago
        You are 100% correct. The product I work on signals this to the user, and asks for confirmation before "upgrading" to an SFU.

Yes, that is the "full mesh" that I mention in my comment... This platform - and jitsi/janus/zoom/whatever - all use an SFU for more than a handful of participants.

fulafel 7y ago

But thats very doable. And no need for the unaccelerated ffmpeg wasm afaics, and no need to use a "sfu". I don't know what Mediasoup does, was just commenting on what webrtc can do re the "the current state of webrtc" subject.

supermatt 7y ago
Do you have any examples of a webrtc video conferencing platform that provides a sufficient user experience over full mesh with 4 or more participants on disparate internet connections? Im just saying that this library (and similar platforms) ARE the cutting edge of webrtc. At small number of participants, they use full mesh (which is e2ee), but at larger scale, they need to use an SFU (which is not e2ee without jumping through some crazy hoops - but this is being worked on)
- fulafel 7y ago
  No (but i hope they exist, havent looked) - however not all webrtc apps are general videoconf platforms. You don't even need servers if you go full p2p.
  - supermatt 7y ago
    You still need servers to handle the signalling, perform ICE and TURN where applicable.
    - fulafel 7y ago
      Only if you need to support users without full internet connectivity. Again webrtc can be used in many different requirement contexts.
      - supermatt 7y ago
        You can certainly manually handle the signalling to set up the offer/answer. e.g. read them out to your peer(s). You would still need some form of STUN server (but there are a number of 'freely accessible' ones, even configured as defaults in some browsers) to get your reachable address/port/proto. You cant, AFAIK, handle this manually - it is handled internally as part of ICE. Then you would need to manually handle the signalling of these as well. Thats the bare minimum you have to do to peer over webrtc under ideal circumstances, but its certainly doable. So you do that for each peer. If you (or a peer) change streams you will do the same thing all over again
        fulafel 7y ago
        STUN is not needed if the participants have full internet connectivity, only if you have to work around NAT.
        supermatt 7y ago
        As mentioned, you cant manually set up your listening ports - this is handled internally by ICE, which needs to connect to a STUN server to get (at a minimum) your public IP address. edit: cant reply to your comment fulafel, but on that project you posted: https://github.com/cjb/serverless-webrtc/blob/master/serverless-webrtc.js#L25 https://github.com/cjb/serverless-webrtc/blob/master/serverl... Also, note that even if this wasnt defined, some browsers contain defaults. You 100% need STUN, but you can handle the signalling manually - as I stated. edit2: cant reply to your comment ibc, but I was explaining the bare minimum 'serverless' webrtc case still required a STUN server. I appreciate that mediasoup SFU uses ice-lite instead.
        fulafel 7y ago
  - ibc 7y ago
    mediasoup co-author here. > You don't even need servers if you go full p2p If you have N participants into the same "room", and do not have a central SFU that relays streams to others, then you have a full mesh network with all participants sending audio and video to all the others. Is that the "go full p2p" you meant?. Well, try it, and you'll see how your CPU burns when the browser/app tries to encode your webcam video source N times. And of course, you'd need N x uplink.
ibc 7y ago
mediasoup co-author here. So you don't know what mediasoup does but you assure that "no need to use a SFU". Too much free time to comment maybe? e2ee makes sense in one-to-one and N-to-N scenarios. It's just more complex in N-to-N scenarios because you DO need a centralized server so each participant just sends its audio/video once (to the server) and the server distributes it to others given whichever application policy/logic. That's a SFU, and that's what mediasoup does.
- fulafel 7y ago
  We may be talking past each other, I'm talking about webrtc in general as the subthread was discussinh that. Think about a limited user count screen sharing or vr app with a/v comms built in for example.
  - ibc 7y ago
    I thought this news was about mediasoup, not about WebRTC in general. Said that I agree that your scenario is valid without any media server.

kabes 7y ago

For some reason I can't reply to fulafel. But a full mesh is definitely not very doable when you're dealing with a larger amount of people. Close to all conferencing solutions today are working via an SFU for a reason. E2E encryption via the SFU gets more and more attention and is being worked into the spec. But it can't be counted as state of the art in webRTC today

fulafel 7y ago
Most calls are not between large amount of people, a portion of webrtc applications would rather compromise on particiant # than security.
- supermatt 7y ago
  For small numbers of participants, many of these platforms use full mesh (which is e2e encrypted).
  - fulafel 7y ago
    Yep, but you can't trust that e2e is a property of the app then, unless it prominently features in the ui.
    - supermatt 7y ago
      You are 100% correct. The product I work on signals this to the user, and asks for confirmation before "upgrading" to an SFU.