--

Agenda:

--

1. H323URL / Directory Search

2. Distributed Directory


--

Attendees:

--

Jason Lynn -- U.A.B.

Aditya Srinivasan -- U.A.B.

John-Paul Robinson -- U.A.B.

Egon Verharen -- SURFnet

Henny Bekker -- SURFnet

Nadim El-Khoury -- U.N.C.

Tyler Johnson -- U.N.C.

Orit Levin -- RADVISION

Danny Lavin -- RADVISION

Sasha Ruditsky -- RADVISION


--

Action Items:

--

* Orit Levin & Sasha Ruditsky - Determine whether or not H323URL is case insensitive.


--

Meeting:

--

Tyler began by saying that the goal for the RADVISION endpoint project

is to provide a self-configuring endpoint, but it is also to provide an

endpoint that is capable of handling H323URLs (clickable dialing).  He

said that it should be a complete environment around the ViDe website.

He mentioned that the Endpoint would be distributed with the RADVISION

protocol stack.


Tyler said to remember that there are two directories, the Enterprise

Directory and the commObject Directory (with pointers in between them).

This, in itself, yields a problem because simple LDAP queries will only

produce a pointer to another directory.  You must then take another step

to get to the commObject.  He mentioned that there are two approaches to

this problem.  One, the group could have a web-enabled search.  And two,

the group could make the client smart enough to follow the pointers.  He

went on to say that clickable dialing from a web-enabled search is good

for some endpoints but it might not be fine for other videoconferencing

appliances.


Egon and Sasha agreed the the web-enabled search would be much better,

in that, it is much easier to implement and most appliances will move

toward HTML if they haven't already.  Egon also said that the clickable

interface is also better, because with the other solution, you must

present all of the information associated with the endpoints which could

be quite a bit of information if you have multiple endpoints.  Tyler

agreed.


Egon said that this just tackles the search portion of the problem and

that there is another part which is the self-configuring section which

is totally different.  Tyler said that this portion will not be going

through the directory of directories.


Tyler asked Orit what is involved in creating a clickable endpoint.

Sasha replied that he has been investigating this lately and that it is

possible now.  All that is needed is proper configuration of Windows.

You only need to specify a scheme and map that scheme to a program that

can handle the URL.  He doesn't know how to do it for Netscape yet, but

it works for Internet Explorer just fine.  Orit said that it is good

news that this is possible.  Tyler asked if this is an easy or hard

thing to accomplish.  Sasha said that there should be no problems.  A

problem would occur if two applications were requesting to use the same

schema [Side Note:  Jason - I think this could be handled in the same

way that Netscape and Internet Explorer exist.  When one starts up and

is not the default client, it says "Whatever is not your default

browser, would you like to make it your default browser?"]


Orit said that the group has a good case now to push Microsoft to make

this standard in their installations.  Tyler thinks that it is up to the

endpoint vendors to make this happen instead of waiting on Microsoft to

do this.


Egon asked if the group needs to define a MIME type for this

architecture.  Sasha said that there should be no need to define a MIME

type as a MIME type only represents the type of file that you are

downloading.  The group is not downloading a file here.  Microsoft did

this same thing, without using a MIME type, with Netmeeting (callto:

schema).  Egon said he mentioned this just because RTSP created a MIME

type and they download a file of this MIME type that just has a URL

inside of it.  But he said that if the group doesn't need to create a

MIME type then the group shouldn't.


Tyler asked Orit if there was anything the group needs to do to push

this in the marketplace.  Orit said that the gatekeeper vendors need to

implement this (like RADVISION is doing).   The gatekeeper should go to

the directory instead of doing an LRQ.  Tyler said that is not what this

architecture is specifying though he believes that Karen is implementing

this, though perhaps not correctly.


Orit said that the correct way of doing a DNS lookup is specified in

Annex O AVD 2331-A which replaces the H.225 Appendix.  Sasha agreed that

Annex O is what needs to be implemented.


Tyler asked if the H323URL is case sensitive.  He said that SIP is from

what Henny has said.  Orit said that she thinks that it is insensitive,

but it needs to be checked on.  It should be located in H323 Version 4.


Egon asked if the group should allow for registering with local dialing

numbers as well as GDS numbers.  Tyler said that, in his opinion, the

group should not do this because it would be a "broken" architecture.

He said the group should use fully qualified numbers.  Egon said that he

was under the impression that if you are using GDS numbers locally that

you involve both the local and national gatekeepers.  Tyler said, no,

this is implementation specific and at U.N.C. this is not the case and

they use GDS numbers.  Egon said he thinks his comments were

misunderstood.  He said that ViDe shows the GDS number, but the user

can register with the local number.  Tyler and Egon agreed that the

gatekeeper can rewrite the local number as the GDS number.  Henny said

that the GDS number should be in the directory and not the local number.


Henny said that the LIMS server has LDAP version 3 redirects to the

original servers.


Egon said that the group should have something on the webpage where site

administrators can specify whether or not they wish to send the TIOs

(which U.A.B. will do).  Egon said that SurfNet wants to collect all of

the TIOs for now (they want to be the TIO "pool").  He said eventually

they need redundancy so that SurfNET is not the single point of

failure.  Henny said that the site administrators will need to provide

an http location (preferably) where SurfNET can download the TIOs.

Tyler said that the group needs to agree, in detail, how this will

work.  Egon says they want to start the testing with SurfNET, U.A.B.,

and U.N.C.


Egon wanted to clarify what the majority of people will be searching

for: for the people, or the endpoints.  He wanted to know if the group

wanted the capability to still look for endpoints only.  Tyler said that

he thinks the group should provide access for searching for people.  He

said the group should gather the rest of the information so that the

commObject directory can be indexed in the future.  Tyler said the group

should have an "Implementing Directory of Directories" Cookbook

section.  Egon said that all of the code for building this is under control by

the group.  Because of that, the group can release the code to trusted sites

for their use in creating a Videoconferencing Middleware infrastructure.


Tyler was speaking about the endpoint user ID and password and said that

the endpoint could write random user ID and password information to the

directory each night.  Egon said that is fine for passwords, but the

group does not want random user IDs.  John-Paul asked what would happen

if a call was placed that ran past midnight (meaning what would happen

if the passwords were out of sync).  Sasha said that the endpoint could

re-register on failure.