Quoting g4sra via Dng (dng@???):

> 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.