*I have added additional method* What is this additional method or mechanism ?
*What I need is: room enter by given SID* simply by SID will not work. Cause the URL contains the $roomId. Otherwise the SWF has to get the ROOMId by doing a RTMP call. But that would mean it has to connect to the default RTMP connection first. So this is not possible. Simply use the scopeRoomId parameter. Sebastian 2013/6/10 Maxim Solodovnik <[email protected]> > - room enter: Most probably you are right :( I'm not really good in all > those "room enter" methods so I have added additional method > I would really appreciate the help in this. > What I need is: room enter by given SID and room id with exit button > visible :) (so the user entered is treated as "normal" OM user, not > external) > > - room close: I have added JS call handling removing of room from the DOM > or just replacing the DOM "the room" element with room list element. > > > On Mon, Jun 10, 2013 at 12:37 PM, [email protected] < > [email protected]> wrote: > >> Quote: >> *Additionally things are simplier in 3.0: >> - Room enter connects to rtmp://xyz/openmeetings/$roomId (use case 1)* >> >> => This is not true. There is such a mechanism, however currently 3.0 >> does not use it. So it will first connect to the scope "hibernate" and then >> to the scope "$roomId". >> However it could be reworked to work like you describe. There is a param >> "scopeRoomId", if that is specified it will directly connect to the scope >> of the room instead of going to hibernate. However there is end the end >> always a check: >> It will request the conference session object from the user and compare >> the roomId with the scopeRoomId, if that test is OK it will directly >> connect to the $roomId, if that test fails, it will connect to the scope >> hibernate and use the "normal" mechanism to get the $roomId and build an >> URL with it. This check is mainly for security reasons, so that by just >> manipulating the URL, the user can gain access to random rooms. >> >> *- Room leave just removes div with embedded flash from the DOM and >> displays >> main interface (use case 2)* >> => Again, it could be done like that but I am not sure if it currenlty >> really does. >> >> Sebastian >> >> >> >> >> >> 2013/6/10 Maxim Solodovnik <[email protected]> >> >>> +1 for displaying "Connection has been lost" >>> >>> Additionally things are simplier in 3.0: >>> - Room enter connects to rtmp://xyz/openmeetings/$roomId (use case 1) >>> - Room leave just removes div with embedded flash from the DOM and >>> displays >>> main interface (use case 2) >>> >>> >>> On Mon, Jun 10, 2013 at 6:55 AM, [email protected] < >>> [email protected]> wrote: >>> >>> > Hi Artyom, >>> > >>> > Quote: *When a user looses his connection he >>> > get 3 attempts to reconnect. * >>> > => Which is a funny co-incident. It should not do that, the 3 times >>> try are >>> > only for when you do your initial set up. It does try 3 times rtmp and >>> then >>> > switches to rtmpt. >>> > >>> > *If we don't, I offer to show user an error message without >>> reconnection >>> > attempts because unexpected leaving the room looks as a bug.* >>> > =>I agree. It should not even try a single time. There should be just >>> an >>> > error message "Your lost the connection, please reload the >>> application". >>> > That would be the correct behaviour. Everything else is just confusing, >>> > cause at the moment it looks like it does some "auto-reconnect". But >>> there >>> > is no such feature. >>> > The only thing to make sure is that room-leave and room(-re)-entering >>> still >>> > works correctly: >>> > - Room enter disconnects from rtmp://xyz/openmeetings/hibernate to >>> > rtmp://xyz/openmeetings/$roomId (use case 1) >>> > - Room leave disconnects from rtmp://xyz/openmeetings/$roomId to >>> > rtmp://xyz/openmeetings/hibernate (use case 2) >>> > - If a user has rtmpt (you can test that by chaning the rtmp port to >>> some >>> > rubbish in the config.xml and clear your cache), then room enter and >>> leaver >>> > should still work the same _but_ using rtmpt instead of rtmp all the >>> time. >>> > (use case 3 [rtmpt-enter] and 4 [rtmpt-leave]) >>> > >>> > You can verify if everything works correctly if you goto >>> Administration > >>> > Connections. If the re-connect on rooms leave is correct, then exiting >>> and >>> > re-entering a room with a user in another session will just increment >>> the >>> > ID of the roomClient by : >>> > Exiting the room +1, >>> > Renering the room +2 (one time SWF8 rtmp connection +1, one time SWF11 >>> > rtmp-connection +1) >>> > If you just close your browser it does not increment the id by +1, just >>> > closing your browser will just disconnect and send appropriate >>> messages to >>> > everybody. >>> > >>> > Administration > Connections is quite handy for development purpsose. >>> On >>> > click of an entry you can see every session attribute in the >>> RoomClient. >>> > You currently always see 2 entries per user as soon as he is in the >>> > conference room. Every user has two separated rtmp connections, one >>> for the >>> > SWF8 legacy code and one for the "new" SWF11 container. SWF11 does >>> handle >>> > all the Audio/Video stuff. SWF11 does only connect when you really need >>> > Audio/Video. So only in the conference room and maybe in the recording >>> > section. >>> > >>> > Maybe part of this information is redundant for you Artyom, however if >>> you >>> > have any further questions please let me know. >>> > >>> > Thanks, >>> > Sebastian >>> > >>> > >>> > 2013/6/7 Artyom Horuzhenko <[email protected]> >>> > >>> > > Sebastian, let me explain our trouble. When a user looses his >>> connection >>> > he >>> > > get 3 attempts to reconnect. If all of the attempts are failed, the >>> user >>> > > sees an error message, otherwise - the user reconnects to dashboard. >>> We >>> > are >>> > > discussing idea about reconnecting to room again instead of >>> dashboard. I >>> > > agree with you that whiteboard, userlist etc should be reloaded, but >>> I >>> > want >>> > > to know if we really need restoring connection. If we don't, I offer >>> to >>> > > show user an error message without reconnection attempts because >>> > unexpected >>> > > leaving the room looks as a bug. >>> > > 07.06.2013 13:28 пользователь "[email protected]" < >>> > > [email protected]> >>> > > написал: >>> > > > >>> > > > Sorry I get lost in that kind of discussion. >>> > > > >>> > > > Artyom started a vote, quote: >>> > > > >>> > > > *I think in this case the functionality like this is useless, >>> > > > it should be removed at all or improved to allow users reconnect >>> > without >>> > > > leaving the room. I offer to vote about this thing: >>> > > > >>> > > > +1 fix leaving rooms >>> > > > 0 don't change anything >>> > > > -1 remove reconnection functionality at all* >>> > > > >>> > > > So what does +1 mean *fix leaving the room* ... what has that to do >>> > with >>> > > > what you say Alexei ?! >>> > > > In fact I don't think that there is anything to fix with that >>> > reconnect. >>> > > > >>> > > > And whatever Artyom proposed has nothing todo with fixing an user >>> that >>> > > lost >>> > > > the connection. >>> > > > >>> > > > About the *reconnect when user lost connection* feature: >>> > > > I think in another thread I tried to explain: When the connection >>> is >>> > > lost, >>> > > > simply reconnecting the rtmp-connection has _no_ meaning, as you >>> don't >>> > > know >>> > > > how long the user was away. You need to re-sync the whiteboard, the >>> > > videos >>> > > > list, the list of participants and the list of current >>> screensharing >>> > > > sessions. So in fact you can simply clean everything and re-login >>> the >>> > > user. >>> > > > The same the other way round, everybody that was in the room, will >>> have >>> > > to >>> > > > re-initialize the user that was lost. Simply connecting the >>> > > rtmp-connection >>> > > > will just make the situation worse as it may look like *working* >>> but in >>> > > > fact nothing really *works*. >>> > > > >>> > > > So I am sorry but from my point of view you mix things together >>> that >>> > have >>> > > > nothing todo with each other: >>> > > > Reconnecting while leaving the room VS connection lost. >>> > > > >>> > > > Sebastian >>> > > > >>> > > > >>> > > > >>> > > > 2013/6/7 Alexei Fedotov <[email protected]> >>> > > > >>> > > > > I used the following arguments: >>> > > > > >>> > > > > 1. Skype tries to re-connect when the connection is lost >>> (though it >>> > > > > works awfully). Why should not we? >>> > > > > 2. When one re-connects (doesn't matter how, maybe after the >>> flash >>> > > > > crash), she should reappear in the place where she was before the >>> > > > > break. This simplifies reestablishing connection. I think this is >>> > > > > useful behavior. >>> > > > > >>> > > > > Combining two of these arguments we get "room reconnect" feature >>> > which >>> > > > > can potentially improve the user experience. >>> > > > > >>> > > > > This is close to the second variant, which is called the cluster >>> > > > > re-connect. >>> > > > > >>> > > > > -- >>> > > > > With best regards / с наилучшими пожеланиями, >>> > > > > Alexei Fedotov / Алексей Федотов, >>> > > > > http://dataved.ru/ >>> > > > > +7 916 562 8095 >>> > > > > >>> > > > > >>> > > > > On Fri, Jun 7, 2013 at 12:47 PM, [email protected] >>> > > > > <[email protected]> wrote: >>> > > > > > Hallo Artyom, >>> > > > > > >>> > > > > > *We know that reconnection works somehow* >>> > > > > > >>> > > > > > Just to be _very_ clear. There is no such feature! >>> > > > > > >>> > > > > > There is a co-incident that may _look like_ a reconnect. >>> > > > > > >>> > > > > > The *feature* is that the flash clients does try to connect 3 >>> times >>> > > to >>> > > > > the >>> > > > > > rtmpconnection. >>> > > > > > This initial connection try out is _never_ cleared. So if your >>> > > > > connections >>> > > > > > gets lost (and you did not have initially the bad luck of using >>> > your >>> > > 3 >>> > > > > > tries), the rtmp connection does reconnect. >>> > > > > > However this is just a funny co-incident. This was never the >>> intend >>> > > to >>> > > > > > re-connect the rtmp connection when it gets lost while the >>> user is >>> > > > > already >>> > > > > > in the meeting. >>> > > > > > >>> > > > > > So what other types of *reconnect* are you refering to? >>> > > > > > There is one reconnect when the user leaves the room, that is >>> when >>> > he >>> > > > > > switches the rtmp connection URL from: >>> > > > > > rtmp://host:port/openmeetings/$roomId >>> > > > > > to >>> > > > > > rtmp://host:port/openmeetings/hibernate (default channel) >>> > > > > > >>> > > > > > The same *re-connect* happens when he enters the room. He has >>> to >>> > > switch >>> > > > > > from the default/global scope to the room scope. >>> > > > > > >>> > > > > > There is no option to remove this functionality, if the user >>> does >>> > not >>> > > > > > change the rtmp-connection he can never receive any messages >>> and >>> > > connect >>> > > > > to >>> > > > > > the streams of the conference room. >>> > > > > > This is the concept of streaming servers: >>> > > > > > If you want to connect to a particular room and receive update >>> > > > > > notifications of events of that room => Connect/Subscribe to >>> that >>> > > URL! >>> > > > > > Connecting/Subscribing to that URL cannot happen without a >>> > reconnect >>> > > when >>> > > > > > you enter or leave the room. >>> > > > > > >>> > > > > > Btw: THis functionality is actually the basis for any kind of >>> > > clustering >>> > > > > as >>> > > > > > the point where somebody enters and leaves the room is when it >>> gets >>> > > > > > re-directed to another server. So without that reconnect, >>> there is >>> > no >>> > > > > > clustering. >>> > > > > > >>> > > > > > So those are the different version of "reconnect" that >>> currently >>> > > exist. >>> > > > > > >>> > > > > > Can you please clarify what exactly you meant with >>> *reconnecting*? >>> > > What >>> > > > > > kind of reconnecting? >>> > > > > > And did you see the impact of your proposal? >>> > > > > > >>> > > > > > Thanks, >>> > > > > > Sebastian >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > 2013/6/7 Artyom Horuzhenko <[email protected]> >>> > > > > > >>> > > > > >> Hello collegues, >>> > > > > >> >>> > > > > >> I want to discuss reconnection again and decide what should >>> we do >>> > > with >>> > > > > it. >>> > > > > >> We know that reconnection works somehow: users leave the room >>> > after >>> > > > > >> reconnection. I think in this case the functionality like >>> this is >>> > > > > useless, >>> > > > > >> it should be removed at all or improved to allow users >>> reconnect >>> > > without >>> > > > > >> leaving the room. I offer to vote about this thing: >>> > > > > >> >>> > > > > >> +1 fix leaving rooms >>> > > > > >> 0 don't change anything >>> > > > > >> -1 remove reconnection functionality at all >>> > > > > >> >>> > > > > >> I made some experiments and suppose that reconnection can be >>> fixed >>> > > > > without >>> > > > > >> global changes in code, but requires deep testing. Anyway, my >>> vote >>> > > is >>> > > > > +1. >>> > > > > >> >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > -- >>> > > > > > Sebastian Wagner >>> > > > > > https://twitter.com/#!/dead_lock >>> > > > > > http://www.webbase-design.de >>> > > > > > http://www.wagner-sebastian.com >>> > > > > > [email protected] >>> > > > > >>> > > > >>> > > > >>> > > > >>> > > > -- >>> > > > Sebastian Wagner >>> > > > https://twitter.com/#!/dead_lock >>> > > > http://www.webbase-design.de >>> > > > http://www.wagner-sebastian.com >>> > > > [email protected] >>> > > >>> > >>> > >>> > >>> > -- >>> > Sebastian Wagner >>> > https://twitter.com/#!/dead_lock >>> > http://www.webbase-design.de >>> > http://www.wagner-sebastian.com >>> > [email protected] >>> > >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >>> >> >> >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> [email protected] >> > > > > -- > WBR > Maxim aka solomax > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
