Quoting g4sra via Dng (dng@lists.dyne.org): > My biggest beef with Microsoft Teams, Zoom, and now Jitsi-meet....they > all omitted an essential service. What I want is (looking at you Rick > :P) a test sever which simply echo's back the incoming video\audio to > the client.
As mentioned, the straightforward way to do this is using two browser tabs, each logged into the same video session, and verifying that you can see and hear yourself. However, the reason I'm posting is to provide tips about a testing site that vets your browser's ability to fully perform the WebRTC videoconferencing protocol suite: https://test.webrtc.org/ My tip: Don't be alarmed at yellow (warning) advisories like a failure of the "Reflexive connectivity" network test. I always get that result, at home, with detailed reporting as follows: [ INFO ] Gathered candidate of Type: srflx Protocol: udp Address: 96.95.217.102 [ WARN ] Could not connect using reflexive candidates, likely due to the network environment/configuration. Point is, above and similar appear to be harmless. (Web-search the detailed warning, if concerned.) However, for a functional test, there's nothing better than the two-tabs method. A more-general tip: _Please_ consider using earbuds or headphones for all Internet videoconferencing. I can't tell you how much time gets wasted on Jitsi Meet, Zoom, etc. sessions trying to figure out which participant is locally re-injecting audio echoed from his/her PC speakers to his/her nearby microphone. It's a huge waste of time. And, as one of the participants using earbuds, I can at least say 'Not it', every time that happens. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng