openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Utkarsh Khokhar <utkarshkhok...@gmail.com>
Subject Re: Reg Openmeetings
Date Tue, 26 Nov 2013 08:51:00 GMT
Now when you explain this scenario, the changes make sense.
However, I believe the ideal solution would be to avoid the user navigation
to anywhere else except the room itself.
Much like when connection is bummed out during a Skype call then Skype
waits till the call gets joined again rather than disconnecting immediately.
I have just started digging into the OM architecture so not sure how hard
this problem is, but I'm sure you guy would have though of this already and
must have some insight into the real challenges with doing this.

thanks


On Tue, Nov 26, 2013 at 12:57 PM, Maxim Solodovnik <solomax666@gmail.com>wrote:

> "redirect.url.for.external.users" is the URL like http://www.google.com
> This URL will be used to redirect users on connection lost.
>
> I suppose this will be the URL of your CMS/External system/Feedback
> form/etc.
>
> In your case if external user (entering the room using secureHash) will be
> dropped out the room other participants will wait for him/her to return.
> In case users invited using invitationHash will have connection problems
> they will be redirected to your CMS and might reenter the room using their
> own links (if still valid)
>
>
> On Tue, Nov 26, 2013 at 2:04 PM, Utkarsh Khokhar
> <utkarshkhokhar@gmail.com>wrote:
>
> > Thanks for the changes Maxim.
> > I have a observation about a possible logical glitch with the new
> > configuration variable "redirect.url.for.external.users"
> >
> > Eg. An OM User enters his meeting room using secureHash and also sends 2
> > different inviteHash for 2 different external users.
> >
> > Inorder to ensure that all the 3 users can stay connected in the same
> room
> > throughout the call, one variable might not be sufficient. For instance
> if
> > I saved the last hash sent (be it secure or invite) as
> > "redirect.url.for.external.users" then only that url will get picked up
> > everytime.
> >
> > Please correct me if I am wrong and missed something here.
> >
> > Utkarsh
> >
> >
> > On Tue, Nov 26, 2013 at 8:31 AM, Maxim Solodovnik <solomax666@gmail.com
> > >wrote:
> >
> > > OK
> > > seems to be fixed
> https://issues.apache.org/jira/browse/OPENMEETINGS-842
> > > here is the patch: http://svn.apache.org/r1545517
> > >
> > > can anyone please test it?
> > >
> > > external users will be redirected to the URL set in admin->config:
> > > "redirect.url.for.external.users"
> > >
> > > the new config key and it's description is added to the docs
> > > http://openmeetings.apache.org/GeneralConfiguration.html
> > >
> > > The changes above will be available here:
> > >
> > >
> >
> https://builds.apache.org/view/M-R/view/OpenMeetings/job/Openmeetings%202.x/
> > > (build
> > > #22)
> > >
> > >
> > >
> > >
> > > On Tue, Nov 26, 2013 at 4:38 AM, Rene' Rosenbaum <rene@meecoda.de>
> > wrote:
> > >
> > > > Dear Maxime,
> > > > may you please let me know which files you modified? We are using a
> > > highly
> > > > customized OM based on v2.1 and thus, have to migrate your
> > modifications
> > > > for now. We'll update quickly when 2.2 is stable enough for
> production.
> > > > We highly appreciate all your efforts to solve this problem,
> > > > Rene'
> > > >
> > > >
> > > > ~~~~~~~
> > > > *Dr.-Ing. Rene' Rosenbaum
> > > > meeCoda^IT  *  - Consulting and Services
> > > >  ~: Neue Reihe 15, 18182 Goorstorf, Germany
> > > >  #: ++49-(0)-1781408041
> > > >  @:info@meecoda.de  <mailto:info@meecoda.de>
> > > > //:www.meecoda.de  <http://www.meecoda.de>
> > > > ~~~~~~~~~~~~~~ +++ ~~~~~~~~~~~~~~~~
> > > >
> > > > On 11/25/2013 6:21 PM, Maxim Solodovnik wrote:
> > > >
> > > >> After fix I need you to test 2.2 build with this feature added.
> > > >> Will write into this thread.
> > > >>
> > > >>
> > > >> On Mon, Nov 25, 2013 at 10:46 PM, Rene' Rosenbaum <rene@meecoda.de>
> > > >> wrote:
> > > >>
> > > >>  Dear Maxim,
> > > >>> that would be great! I think a solution is of value for many
> adopters
> > > of
> > > >>> OM embedding the software in their websites. Please let me know
> when
> > > you
> > > >>> need any support or further information ...
> > > >>> Cheers,
> > > >>> Rene'
> > > >>> PS: We can sometimes reproduce the problem when suddenly switching
> > off
> > > >>> the
> > > >>> network (plugging off). Works often with local installation, but
> less
> > > >>> with
> > > >>> second server machine.
> > > >>>
> > > >>>
> > > >>> ~~~~~~~
> > > >>> *Dr.-Ing. Rene' Rosenbaum
> > > >>> meeCoda^IT  *  - Consulting and Services
> > > >>>   ~: Neue Reihe 15, 18182 Goorstorf, Germany
> > > >>>   #: ++49-(0)-1781408041
> > > >>>   @:info@meecoda.de  <mailto:info@meecoda.de>
> > > >>> //:www.meecoda.de  <http://www.meecoda.de>
> > > >>> ~~~~~~~~~~~~~~ +++ ~~~~~~~~~~~~~~~~
> > > >>>
> > > >>> On 11/25/2013 4:24 PM, Maxim Solodovnik wrote:
> > > >>>
> > > >>>  I'll try to reproduce add code for this
> > > >>>>
> > > >>>>
> > > >>>> On Mon, Nov 25, 2013 at 10:19 PM, Rene' Rosenbaum <
> rene@meecoda.de>
> > > >>>> wrote:
> > > >>>>
> > > >>>>   Hi all,
> > > >>>>
> > > >>>>> first of all, thanks for all the good work of the team
so far. We
> > are
> > > >>>>> using OM as a conferencing solution, part of a larger
website. We
> > are
> > > >>>>> facing similar issues as described before: from time to
time, a
> > > >>>>> conferencing session crashes*and the user is then referred
to the
> > > start
> > > >>>>> page/dashboard of the OM backend*. As we are not working
with the
> > > >>>>> backend
> > > >>>>> at all (all user management is done via the website),
we have a
> > huge
> > > >>>>> problem here. We adapted the URL in the "onerror"-handler
(in
> > > >>>>> hibRtmpConnection.lzx), but this didn't do the trick:
the stated
> > URL
> > > is
> > > >>>>> not
> > > >>>>> called.
> > > >>>>>
> > > >>>>> ---------------------
> > > >>>>> <handler name="onerror" >
> > > >>>>>           <![CDATA[
> > > >>>>>                       ...
> > > >>>>> canvas.thishib.loaderVar.error.setAttribute('text',this.status);
> > > >>>>> canvas.setAttribute('loadingmessage','connection failed');
> > > >>>>>                       new lz.labelerrorPopup(canvas,{
> > > >>>>> errorlabelid:556});
> > > >>>>>                   }
> > > >>>>> *canvas.thishib.loaderVar._src.setAttribute('text','http:
> > > >>>>> //www.google.de/');*
> > > >>>>> //canvas.thishib.loaderVar._src.setAttribute('text',src);
> > > >>>>>               }
> > > >>>>>           ]]>
> > > >>>>>       </handler>
> > > >>>>> ---------------------
> > > >>>>>
> > > >>>>> Do you guys have an idea what we can do here to refer
the user to
> > an
> > > >>>>> arbitrary URL and not the dashboard?
> > > >>>>>
> > > >>>>> Setup details:
> > > >>>>> - OM v2.1
> > > >>>>> - just using the conferencing part embedded via SOAP/REST
into an
> > > >>>>> iframe
> > > >>>>> - complete setup of a conference via SOAP/REST (users,
documents,
> > > etc.)
> > > >>>>>
> > > >>>>> Thanks for all your help,
> > > >>>>> Rene'
> > > >>>>> --
> > > >>>>>
> > > >>>>> ~~~~~~~
> > > >>>>> *Dr.-Ing. Rene' Rosenbaum
> > > >>>>> meeCoda^IT  *  - Consulting and Services
> > > >>>>>    ~: Neue Reihe 15, 18182 Goorstorf, Germany
> > > >>>>>    #: ++49-(0)-1781408041
> > > >>>>>    @:info@meecoda.de  <mailto:info@meecoda.de>
> > > >>>>> //:www.meecoda.de  <http://www.meecoda.de>
> > > >>>>> ~~~~~~~~~~~~~~ +++ ~~~~~~~~~~~~~~~~
> > > >>>>>
> > > >>>>> On 11/25/2013 10:02 AM, Maxim Solodovnik wrote:
> > > >>>>>
> > > >>>>>   I believe this will be resolved in 3.1.
> > > >>>>>
> > > >>>>>>
> > > >>>>>> On Mon, Nov 25, 2013 at 2:37 PM, Utkarsh Khokhar
> > > >>>>>> <utkarshkhokhar@gmail.com>wrote:
> > > >>>>>>
> > > >>>>>>    I am dealing with the exact same problem at my
end.
> > > >>>>>>
> > > >>>>>>  Anyone who joins a room directly through secureHash
or
> inviteHash
> > > >>>>>>> gets
> > > >>>>>>> disconnected at times, due to network issue, and
taken back to
> > > >>>>>>> dashboard.
> > > >>>>>>> I believe this is quite a fundamental problem.
I am yet to dive
> > > into
> > > >>>>>>> this
> > > >>>>>>> completely but it would be great to learn from
others on this
> > forum
> > > >>>>>>> who
> > > >>>>>>> might have a prior insight on this.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> On Mon, Nov 25, 2013 at 12:51 PM, Maxim Solodovnik
<
> > > >>>>>>> solomax666@gmail.com
> > > >>>>>>>
> > > >>>>>>>   wrote:
> > > >>>>>>>
> > > >>>>>>>> If I'm not mistaken, Sebastian told it is
impossible to
> > reconnect
> > > >>>>>>>> user
> > > >>>>>>>> to
> > > >>>>>>>> the same scope ...
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Mon, Nov 25, 2013 at 1:58 PM, sanjeev kumar
<
> > > >>>>>>>> sanjeev1048@gmail.com
> > > >>>>>>>>
> > > >>>>>>>>   wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Dear Sir
> > > >>>>>>>>>         I want add functionality to reconnect
user in the
> same
> > > >>>>>>>>> scope
> > > >>>>>>>>> while
> > > >>>>>>>>> his NetConnection lost due to
> > NetConnection.connect.NetworkChange
> > > >>>>>>>>> or
> > > >>>>>>>>>
> > > >>>>>>>>>   Closed.
> > > >>>>>>>>>
> > > >>>>>>>>          when any event generates other than
Success it is
> going
> > > to
> > > >>>>>>>>
> > > >>>>>>>>> onerror
> > > >>>>>>>>> (in hibRtmpConnection.lzx ) handler there
it is disconnecting
> > > from
> > > >>>>>>>>> the
> > > >>>>>>>>> current scope and connecting to default
scope.
> > > >>>>>>>>>        so how i can reconnect to same
scope again.....
> > > >>>>>>>>> what i am doing , from onerror handler
it self i am calling
> > > >>>>>>>>>
> > > >>>>>>>>>   this.connect()
> > > >>>>>>>>>
> > > >>>>>>>>   but in the userlist multiple entries are
coming for same
> user
> > ,
> > > >>>>>>>> so i
> > > >>>>>>>>
> > > >>>>>>>>>   want
> > > >>>>>>>>>
> > > >>>>>>>> to know correct way of reconnecting in to
same scope
> > > automatically.
> > > >>>>>>>>
> > > >>>>>>>>  please help me.....
> > > >>>>>>>>>
> > > >>>>>>>>> Thanks & Regards
> > > >>>>>>>>> Sanjeev Kumar
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>   --
> > > >>>>>>>>>
> > > >>>>>>>> WBR
> > > >>>>>>>> Maxim aka solomax
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>
> > > >
> > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message