... room enter by given SID* simply by SID will not work => will of course work, but what I meant was: It will not work without connecting to the default scope as the roomid is needed for the URL.
Sebastian 2013/6/10 [email protected] <[email protected]> > *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] > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
