Re: Re: [GnomeMeeting-list] no ringing tone with phonejack pci and headset

[Malcolm Caldwell <malcolm caldwell ntu edu au>]

On Mon, 2004-06-21 at 17:47, Damien Sandras wrote:
> Le lun, 21/06/2004 �7:31 +0930, Malcolm Caldwell a �it :
> 
> > What state information will be lacking?
> > 
> > If the ldap server communicates with the gatekeeper you can find out
> > 1) if someone is on line
> > 2) if someone is in a current call
> > 
> 
> If we add a state notion to determine if somebody is currently in a call
> or not, we fall again in the non-standard case with non-standard
> attributes like with ILS.

IMHO the non-standard attributes are not the biggest problem with ILS. 
Its hacking up the actual LDAP protocol, and using LDAP to 

I don't think there is anything wrong with extending an LDAP database
with additional attributes.  Adding additional attributes for additional
functionality does not make the system non complient.

The system is still H350 complient - any software that wants to query
the LDAP directory looking for H350 attributes will work just fine.

The whole system is standards compliant:
      * The gatekeeper looks to its endpoints like any other gatekeeper
      * The endpoints communicate with their gatekeepers and H350 using
        standard protocols

This solution will allow non gnomemeeting endpoints to register to the
directory just fine.  It will also allow gnomemeeting to work with any
other gatekeeper and h350 server just fine as well.  Gnomemeeting could
even check for the presence of our 'state' attribute and only show the
field if it exists.

So, the only thing different is that one attribute contains 'live'
information about an endpoints state.  I would argue that such a system
IS standards compliant.

If this state information is in a comment field (as well as a separate
attribute) it is even visible to normal H350 browsers!

(Please note, I am no H350 expert.  I have had a quick look at the H350
cookbook at http://metric.it.uab.edu/vnet/cookbook/ and cannot see
anything wrong with my proposal)

> That's the only thing that should be missing though.
> 
> H.350 defines a set of LDAP schemas permitting :
> - to H.323 clients to browse directories of H.323 people
> - to H.323 gatekeepers to use the H.350 scheme to authentify people
> 
> There is no ntion of state, however you can use any LDAP attribute you
> want for the rest (comment, location, ...)
> 
> Doing that would permit to have a big directory of GnomeMeeting users,
> but if we use the same LDAP repository to authentify and list people,
> then we won't have a way to know if somebody is online or not. That is
> well-suited for companies, but not for seconix.com.
> 
> My idea was to :
> - have the static information of people and the authentication stored in
> a SQL database
> - the gatekeeper uses that database to authentify people

(Or the gatekeeper can use LDAP to authenticate people.  Yet perhaps the
database is better - see below)

> - the gatekeeper reads the static information in the database and push
> it to the LDAP server when people login, and remove it when they logoff
> or when the gatekeeper timeout is elapsed

Another approach is:
store all the information in the database.
      * LDAP server has a database backend
      * Gatekeeper authenticates users via database
      * Gatekeeper 'publishes' its information to the database

Would it be hard to modify opengk to do this publishing?  (Is it just a
matter of overriding various OnXXX calls to call the original code and
then update the database with the results?)

> Any comment?
> 
> > What is needed is a gw between the gatekeeper and the ldap server. 
> > opengk could be extended to 'publish' its state to the ldap server. 
> > Alternatively the ldap server could query the gatekeeper for this
> > information.
> >