6 ms·

I've had a WebRTC app tested working under multiple OS's (Windows, Linux, Android) and browsers (Chrome, Firefox, IE, Chrome for Android). It did take more tha

I've had a WebRTC app tested working under multiple OS's (Windows, Linux, Android) and browsers (Chrome, Firefox, IE, Chrome for Android). It did take more than a month to get to that point though.

moron4hire 10y ago
Repo or it didn't happen.
- jsprogrammer 10y ago
  https://github.com/blakelapierre/instantfile https://github.com/blakelapierre/instantfile https://github.com/blakelapierre/instantchat https://github.com/blakelapierre/instantchat Can't say whether the HEADs work or not. They currently aren't hosted live at the moment, either.
  - moron4hire 10y ago
    So other than hosting your own TURN server, you're not doing anything that my own home grown code was doing, leading me to believe that this will not work very reliably. My problem wasn't making confections, it was making them reliably.
    - jsprogrammer 10y ago
      You must follow the 52ish-step handshake protocol pretty much exactly to have any hope of reliably creating connections across OS/browser platforms. I don't think I had seen any handshake failures in the final versions of the code in those projects. Also, you need a TURN to work reliably over every possible NAT topology (though, a few years ago I think only about 5% of connections in the wild required TURN).
      - moron4hire 10y ago
        I had a TURN server, I just meant I didn't host it myself. But the metering showed it was never active! I kept getting a connection that succeeded through STUN, but no audio would actually come through in about 50% of WAN cases. It would always work on the LAN. Is it possible to just have a janky STUN server that negotiated a bad connection for you? Seems like a really weird failure mode. I was using Xirsys at the time as they have a mostly bare-bones setup.
        jsprogrammer 10y ago
        If you were going across browser versions/platforms, it's possible that an appropriate audio codec couldn't be negotiated...perhaps some browsers use different codecs for different network conditions? It seems unlikely, but possible. So, you had video, but no audio?
        moron4hire 10y ago
        No, I wasn't using video. This is for a WebVR app, so the people are rendered as avatars.
        jsprogrammer 10y ago
        So, you were still getting a data connection, just no audio?

I've had a WebRTC app tested working under multiple OS's (Windows, Linux, Android) and browsers (Chrome, Firefox, IE, Chrome for Android). It did take more than a month to get to that point though.

moron4hire 10y ago

Repo or it didn't happen.

jsprogrammer 10y ago
https://github.com/blakelapierre/instantfile https://github.com/blakelapierre/instantfile https://github.com/blakelapierre/instantchat https://github.com/blakelapierre/instantchat Can't say whether the HEADs work or not. They currently aren't hosted live at the moment, either.
- moron4hire 10y ago
  So other than hosting your own TURN server, you're not doing anything that my own home grown code was doing, leading me to believe that this will not work very reliably. My problem wasn't making confections, it was making them reliably.
  - jsprogrammer 10y ago
    You must follow the 52ish-step handshake protocol pretty much exactly to have any hope of reliably creating connections across OS/browser platforms. I don't think I had seen any handshake failures in the final versions of the code in those projects. Also, you need a TURN to work reliably over every possible NAT topology (though, a few years ago I think only about 5% of connections in the wild required TURN).
    - moron4hire 10y ago
      I had a TURN server, I just meant I didn't host it myself. But the metering showed it was never active! I kept getting a connection that succeeded through STUN, but no audio would actually come through in about 50% of WAN cases. It would always work on the LAN. Is it possible to just have a janky STUN server that negotiated a bad connection for you? Seems like a really weird failure mode. I was using Xirsys at the time as they have a mostly bare-bones setup.
      - jsprogrammer 10y ago
        If you were going across browser versions/platforms, it's possible that an appropriate audio codec couldn't be negotiated...perhaps some browsers use different codecs for different network conditions? It seems unlikely, but possible. So, you had video, but no audio?
        moron4hire 10y ago
        No, I wasn't using video. This is for a WebVR app, so the people are rendered as avatars.
        jsprogrammer 10y ago
        So, you were still getting a data connection, just no audio?