[
https://issues.apache.org/jira/browse/OPENMEETINGS-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Sop updated OPENMEETINGS-928:
----------------------------------
Description:
Not sure all of this info is necessary but figure it cant hurt
I run openmeetings from windows via the "red5.bat" (not sure if you need this
run with the red5-debug.bat, but hte logs seem to be pretty verbose so
hopefully they can point ot the problem)
I sent a conference invite with max 5 users, 4 of us joined and had a wierd
mesh of connections i.e. user 1 was able to hear user 2 and 3, but only user 3
could hear him. User 2 could only hear user 1 and 4, user 4 could only hear
user 2, etc. On retry we had a different broken mesh of connections (wasnt
consistently same users able to hear same users)
Is the audio a peer to peer connection, or does the server act as a
"reboradcaster"? Either way I suspect the issue is with establishing those
initial connections, since if it were a bandwidth issue I wouldnt expect the
disconnect to persist for the entire meeting (i.e. the same users can hear same
subset of users through duration of the meeting) however like I mentioned, on
a 2nd try (after server restart, rejoin a room) we had a different ordering of
disconnects, but still not a perfect mesh of connections (seems like a 50/50
chance of connection (each direction) being preoperly established, since we
could all speak to about half the people, and hear from about half the people,
but that set of people you can speak to is not the same as those you can hear
(so the "to" and "from" connections are also distinct I'm guessing)
Even with the audio problems, we were all able to use the group chat, and were
all able to see each otehrs webcams, just seemed to be a problem with the audio
initilizing. I've attached my logs in case it helps, unforutnately I dont
recall start/end times of attempts, but the server was started/stopped shortly
before/after our meeting attempt (I tried a reboot of the server to see if it
would fix the issue but no luck)
Also FWIW I did a testrun with 2 users a day before our group meeting which was
fine, we both joined a public room from the dashboard (not a meeting via
created conference i.e. from link in conference invite email) so not sure if
that could be related, or if is just an issue with > 2 users (I suspect the
latter)...
Anyway let me know if you need more info (if this isnt easy to reproduce on
your end) Seems like would be a pretty obvious bug for other users but not
seeing it listed (sorry if this is a dup)
was:
Not sure all of this info is necessary but figure it cant hurt
I run openmeetings from windows via the "red5.bat" (not sure if you need this
run with the red5-debug.bat, but hte logs seem to be pretty verbose so
hopefully they can point ot the problem)
I sent a conference invite with max 5 users, 4 of us joined and had a wierd
mesh of connections i.e. user 1 was able to hear everyone, but only user 2 and
3 could hear him. User 2 could only hear user 1 and 4, user 4 could only hear
user 2, etc.
Is the audio a peer to peer connection, or does the server act as a
"reboradcaster"? Either way I suspect the issue is with establishing those
initial connections, since if it were a bandwidth issue I wouldnt expect the
disconnect to be persistent for the entire meeting (i.e. the same users can
hear same subset of users through duration of the meeting) however on a 2nd
try we had a different ordering of disconnects, but still not a perfect mesh of
connections
We were all able to use the group chat, and were all able to see each otehrs
webcams, just seemed to be a problem with the audio initilizing. I've attached
my logs in case it helps, unforutnately I dont recall start/end times of
attempts, but the server was started/stopped shortly before/after our meeting
attempt (I tried a reboot of the server to see if it would fix the issue but no
luck)
Also FWIW I did a testrun with 2 users a day before our group meeting which was
fine, we both joined a public room from the dashboard (not a meeting via
created conference i.e. from link in conference invite email) so not sure if
that could be related, or if is just an issue with > 2 users (I suspect the
latter)...
Anyway let me know if you need more info (if this isnt easy to reproduce on
your end) Seems like would be a pretty obvious bug for other users but not
seeing it listed (sorry if this is a dup)
> audio mesh not establishing some connections
> --------------------------------------------
>
> Key: OPENMEETINGS-928
> URL: https://issues.apache.org/jira/browse/OPENMEETINGS-928
> Project: Openmeetings
> Issue Type: Bug
> Components: Audio/Video
> Affects Versions: 2.2.0 Apache Release
> Environment: Server is running: Windows 7 x64, openmeetings 2.2.0
> Client: not sure about the others but I was running chrome (I can find out
> what browsers others were using if that may be relevent)
> Reporter: Mike Sop
> Priority: Critical
> Attachments: openmeetings.log, red5.log
>
>
> Not sure all of this info is necessary but figure it cant hurt
> I run openmeetings from windows via the "red5.bat" (not sure if you need this
> run with the red5-debug.bat, but hte logs seem to be pretty verbose so
> hopefully they can point ot the problem)
> I sent a conference invite with max 5 users, 4 of us joined and had a wierd
> mesh of connections i.e. user 1 was able to hear user 2 and 3, but only user
> 3 could hear him. User 2 could only hear user 1 and 4, user 4 could only
> hear user 2, etc. On retry we had a different broken mesh of connections
> (wasnt consistently same users able to hear same users)
> Is the audio a peer to peer connection, or does the server act as a
> "reboradcaster"? Either way I suspect the issue is with establishing those
> initial connections, since if it were a bandwidth issue I wouldnt expect the
> disconnect to persist for the entire meeting (i.e. the same users can hear
> same subset of users through duration of the meeting) however like I
> mentioned, on a 2nd try (after server restart, rejoin a room) we had a
> different ordering of disconnects, but still not a perfect mesh of
> connections (seems like a 50/50 chance of connection (each direction) being
> preoperly established, since we could all speak to about half the people, and
> hear from about half the people, but that set of people you can speak to is
> not the same as those you can hear (so the "to" and "from" connections are
> also distinct I'm guessing)
> Even with the audio problems, we were all able to use the group chat, and
> were all able to see each otehrs webcams, just seemed to be a problem with
> the audio initilizing. I've attached my logs in case it helps, unforutnately
> I dont recall start/end times of attempts, but the server was started/stopped
> shortly before/after our meeting attempt (I tried a reboot of the server to
> see if it would fix the issue but no luck)
> Also FWIW I did a testrun with 2 users a day before our group meeting which
> was fine, we both joined a public room from the dashboard (not a meeting via
> created conference i.e. from link in conference invite email) so not sure if
> that could be related, or if is just an issue with > 2 users (I suspect the
> latter)...
> Anyway let me know if you need more info (if this isnt easy to reproduce on
> your end) Seems like would be a pretty obvious bug for other users but not
> seeing it listed (sorry if this is a dup)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
