LDP/LDP/howto/docbook/NetMeeting-HOWTO.sgml

1374 lines
50 KiB
Plaintext

<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<article id="index">
<!-- Header -->
<artheader>
<title>Linux NETMEETING HOWTO</title>
<author>
<firstname>Brent</firstname>
<surname>Baccala</surname>
<affiliation>
<address>
<email>baccala@freesoft.org</email>
</address>
</affiliation>
</author>
<author>
<firstname>Martin</firstname>
<surname>Schiffers</surname>
<affiliation>
<address>
<email>mschiffers@axsi.net</email>
</address>
</affiliation>
</author>
<othercredit role='converter'>
<firstname>Mark</firstname>
<othername>F.</othername>
<surname>Komarinski</surname>
<contrib>Conversion from HTML to DocBook 3.1</contrib>
</othercredit>
<revhistory>
<revision>
<revnumber>v1.2</revnumber>
<date>15 January 2002</date>
<authorinitials>bwb</authorinitials>
<revremark>
Updated ndk-1.2; handles newer versions of openldap.
Added pointers to mailing list
</revremark>
</revision>
<revision>
<revnumber>v1.1</revnumber>
<date>31 March 2001</date>
<authorinitials>bwb</authorinitials>
<revremark>
Updated ndk-1.1; handles accented European characters
</revremark>
</revision>
<revision>
<revnumber>v1.0</revnumber>
<date>13 January 2001</date>
<authorinitials>bwb</authorinitials>
<revremark>
Initial public release
</revremark>
</revision>
<revision>
<revnumber>v0.11</revnumber>
<date>25 October 2000</date>
<authorinitials>mfk</authorinitials>
<revremark>
Conversion to DocBook
</revremark>
</revision>
</revhistory>
<abstract>
<para>
This document aims to describe how to make Microsoft NetMeeting
interoperate with Linux.
</para>
</abstract>
</artheader>
<section id="introduction">
<title>Introduction</title>
<para>
This is the Linux NETMEETING HOWTO; it describes
how to configure Linux for interoperation with Microsoft NetMeeting.
The latest copy of this document is available at
<ulink url="http://www.freesoft.org/software/NetMeeting/">http://www.freesoft.org/software/NetMeeting</ulink>
or from the
<ulink url="http://www.linuxdoc.org/">Linux Documentation Project</ulink>.
<email>software/NetMeeting@freesoft.org</email>
is a mailing list to discuss Linux NetMeeting interoperation;
consult its <ulink url="http://www.freesoft.org/software/NetMeeting/mailinglist/">archive</ulink> if you have questions unanswered in this HOWTO.
</para>
<para>
NetMeeting is Microsoft's client implementation of the H.323
international standard teleconferencing protocol suite, providing
audio and video conferencing over an IP network.
NetMeeting also implements
the T.120 protocol suite, providing shared whiteboard, file
transfer and application sharing. As an extension, LDAP is
used for directory service. NetMeeting is included in Windows 2000
and is freely available for download from
<ulink url="http://www.microsoft.com/windows/netmeeting">http://www.microsoft.com/windows/netmeeting</ulink>
for Windows 95, 98, and NT.
</para>
<para>
Linux software is presently (October 2000) available to support H.323
(both audio and video) and LDAP directory service, but not T.120 shared
whiteboard, file transfer, or application sharing.
</para>
<para>
If you don't know anything about H.323, I recommend these links:
</para>
<itemizedlist>
<listitem>
<para>
<ulink url="http://www.openh323.org/">http://www.openh323.org/</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="http://www.databeam.com/h323/h323primer.html">http://www.databeam.com/h323/h323primer.html</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="http://www.hut.fi/~tttoivan/index4.html">http://www.hut.fi/~tttoivan/index4.html</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="http://developer.intel.com/technology/itj/q21998/articles/art_4.htm">http://developer.intel.com/technology/itj/q21998/articles/art_4.htm</ulink>
</para>
</listitem>
</itemizedlist>
<para>
If you don't know anything about LDAP, I recommend these links:
</para>
<itemizedlist>
<listitem>
<para>
<ulink url="http://www.openldap.org/">http://www.openldap.org/</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="http://www.umich.edu/~dirsvcs/ldap/index.html">http://www.umich.edu/~dirsvcs/ldap/index.html</ulink>
</para>
</listitem>
<listitem>
<para>
RFCs 2251-2256
</para>
</listitem>
</itemizedlist>
<para>
If you have other links to recommend, or other suggestions for
improving this document, please email me at
<email>baccala@freesoft.org</email>, or even better email
<email>software/NetMeeting@freesoft.org</email>
</para>
</section>
<section id="OpenH323">
<title>OpenH323</title>
<section id="whatish323">
<title>What is it?</title>
<para>
OpenH323 is an open source implementation of the H.323 protocol suite.
As such, it can directly interoperate with Microsoft NetMeeting. At
the time of this writing (October 2000), OpenH323 is still early
in its development cycle; buggy and in flux, but useful.
</para>
<para>
OpenH323 consists of several C++ libraries and some C++
client programs.
</para>
<para>
The most useful client programs are:
</para>
<table>
<title>
List of client applications
</title>
<tgroup cols="2">
<tbody>
<row>
<entry>ohphone</entry>
<entry>
H.323 interactive client. Linux equivalent to NetMeeting.
Supports audio and video;
no shared whiteboard, file transfer, or shared applications
</entry>
</row>
<row>
<entry>openam</entry>
<entry>
H.323 answering machine. Plays back a recorded message
and records incoming audio. No video support at present.
</entry>
</row>
<row>
<entry>forwarder</entry>
<entry>
Forwards H.323 sessions from one IP address/port to
another. Used to serve multiple H.323 destinations
from a single IP address.
</entry>
</row>
<row>
<entry>openmcu</entry>
<entry>
Multipoint Control Unit. Connects multiple sessions together
into a conference call.
</entry>
</row>
<row>
<entry>PSTN Gateway</entry>
<entry>
Allows NetMeeting clients to make phone calls onto the
conventional phone system - the Public Switched Telephone
Network (PSTN). Requires special hardware.
</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
OpenH323 presently (October 2000) supports audio codecs G.711, G.723.1,
LPC-10, and GSM 06.10, as well as video codec H.261.
</para>
</section>
<section id="whyneed">
<title>Why is it needed?</title>
<para>
OpenH323 is needed only if you want to make audio/video connections
with NetMeeting clients directly from your Linux system. It is not
needed to provide LDAP directory service to NetMeeting clients.
</para>
</section>
<section id="wheretoget">
<title>Where to get it?</title>
<para>
The main site is <ulink url="http://www.openh323.org/">http://www.openh323.org/</ulink>
and contains links to a download page, mirror sites, mailing lists,
and other resources.
</para>
<para>
OhPhone, OpenAM, and PSTNgw are available as part of the standard
distribution, in both source and executable formats.
forwarder and openmcu are presently (December 2000) only available
from the CVS archive, as modules named "forwarder" and "openmcu".
</para>
</section>
<section id="install">
<title>Installation</title>
<para>
For OhPhone, OpenAM, and PSTNgw, download the executables.
If you want to build from source, perhaps because you need
forwarder or openmcu, you'll need the source code to the programs,
as well as to the pwlib and openh323 libraries. Compilation
instructions are available on the openh323 website.
</para>
</section>
<section id="gatekeepers">
<title>Gatekeepers</title>
<para>
OpenH323 doesn't provide any gatekeepers itself, but several are
under construction based on its libraries. As of the end of 2000,
most of them are actively under development and quite primitive.
I haven't used any of them myself, but you want may to examine the
following links:
</para>
<itemizedlist>
<listitem>
<para>
<ulink url="http://www.opengatekeeper.org/">OpenGatekeeper</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="http://www.willamowius.de/openh323gk.html">OpenH323 Gatekeeper</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="http://openh323proxy.sourceforge.net/">OpenGatekeeper H323 Proxy</ulink>
</para>
</listitem>
</itemizedlist>
</section>
</section>
<section id="netmeetserver">
<title>NetMeeting directory kit</title>
<section id="whatisnetmeet">
<title>What is it?</title>
<para>
Each NetMeeting client can register with an LDAP server and
has a directory window that lists other
NetMeeting clients registered with the same server.
The NetMeeting directory kit is an extension to the OpenLDAP server
that provides directory service to NetMeeting clients.
</para>
</section>
<section id="whyneednetmeet">
<title>Why is it needed?</title>
<para>
While NetMeeting can connect directly to another H.323 device by
specifying an IP address or DNS name, normally you'll want to use
an LDAP directory server. Using an LDAP server lets users see
a directory listing of available destinations, and is required
if you need to resolve aliases, for example if you want to serve
multiple H.323 destinations from a single IP address. A directory
server isn't required to connect directly from Linux
to a NetMeeting client; use OpenH323 for this.
</para>
<para>
The NetMeeting client violates the LDAP protocol in several ways,
so you'll have problems if you try using a standard LDAP server.
The NetMeeting directory kit corrects for these problems and allows
an OpenLDAP server to be used for NetMeeting directory service.
</para>
</section>
<section id="howitworks">
<title>How it works</title>
<screen>
Block diagram of NetMeeting directory kit
___________________ _______ __________________ ______________
| LDAP server | request | | | LDAP server | request| |
| | <-------| Perl |<--| | <------| NetMeeting |
| on private port | |script| | on public port | | client |
| (i.e, 2345) |-------> | |-->| 389 |------->| |
| | reply -------- | | reply --------------
| | | |
------------------- ------------------
</screen>
<para>
The directory server consists of a 'master' LDAP server to
receive requests, a Perl script to correctly interpret
the Microsoft NetMeeting requests and, after interrogation
of a 'hidden' LDAP server, formats the results in a way that the
NetMeeting client can understand.
OpenLDAP's 'shell backend' is used to call the Perl script.
A custom schema is also required.
The script presently handles all of the above problems, with the
exception of timing out entries, which it doesn't do.
</para>
</section>
<section id="wheretogetsoftware">
<title>Where to get the software</title>
<para>
First of all you need to get the OpenLDAP software.
</para>
<note>
<para>
Pre-built OpenLDAP software (i.e, RPMs) won't work unless
configured with support for the shell backend.
</para>
</note>
<para>
You can download OpenLDAP from the main site located at
<ulink url="ftp://ftp.OpenLDAP.org/pub/OpenLDAP/openldap-release/">ftp://ftp.OpenLDAP.org/pub/OpenLDAP/openldap-release/</ulink>
or any mirror.
I've successfully used OpenLDAP 2.0.7.
</para>
<para>
The NetMeeting directory kit is available from
<ulink url="http://www.freesoft.org/software/NetMeeting/download">http://www.freesoft.org/software/NetMeeting/download</ulink>.
</para>
<para>
You need Perl 5, available from
<ulink url="http://www.perl.org/">http://www.perl.org</ulink>,
but already included in all common Linux distributions.
You will also need the Net::LDAP module from the Perl CPAN archive,
which can be downloaded and installed directly from Perl:
</para>
<screen>
[root@y2k baccala]# <userinput>perl -MCPAN -e shell</userinput>
cpan shell -- CPAN exploration and modules installation (v1.58)
ReadLine support enabled
cpan> <userinput>install Net::LDAP</userinput>
... much output omitted ...
/usr/bin/make install -- OK
cpan>
</screen>
<para>
If you've never used CPAN before, you will be prompted first with
a series of configuration questions. Once CPAN is configured,
the Net::LDAP module will be downloaded, compiled, and installed
automatically.
</para>
</section>
<section id="installsoftware">
<title>Installation</title>
<para>
Building OpenLDAP will require approximately 60 MB of free disk
space. Untar OpenLDAP and configure it.
</para>
<note>
<para>
Be sure to specify the shell backend function "--enable-shell"
</para>
</note>
<para>
I also recommend specifying "--disable-debug" to prevent OpenLDAP
from exiting if an assertion fails.
</para>
<screen>
bash$ <userinput>./configure --enable-shell --disable-debug</userinput>
</screen>
<para>
Now build and install it with:
</para>
<screen>
bash$ <userinput>make</userinput>
... much output omitted ...
bash# <userinput>make install</userinput>
</screen>
<para>
It will normally install under <filename class=directory>/usr/local</filename>:
</para>
<table>
<title>
Directories used by OpenLDAP
</title>
<tgroup cols=2>
<tbody>
<row>
<entry>
<filename class=directory>/usr/local/lib</filename>
</entry>
<entry>
Shared and static libraries
</entry>
</row>
<row>
<entry>
<filename class=directory>/usr/local/bin</filename>
</entry>
<entry>
Client binaries for adding, deleting,
and searching LDAP servers
</entry>
</row>
<row>
<entry>
<filename class=directory>/usr/local/sbin</filename>
</entry>
<entry>
Utility programs for manipulating the raw database files.
Not needed for normal operation.
</entry>
</row>
<row>
<entry>
<filename class=directory>/usr/local/libexec</filename>
</entry>
<entry>
Various server programs,
including the <command>slapd</command> binary
</entry>
</row>
<row>
<entry>
<filename class=directory>/usr/local/etc/openldap</filename>
</entry>
<entry>
Contains the default configuration files
</entry>
</row>
<row>
<entry>
<filename class=directory>/usr/local/etc/openldap/schema</filename>
</entry>
<entry>
The different schemas used by the LDAP servers.
</entry>
</row>
<row>
<entry>
<filename class=directory>/usr/local/var/...</filename>
</entry>
<entry>
The location of the LDAP databases (in subdirectories)
</entry>
</row>
<row>
<entry>
<filename class=directory>/usr/local/man/...</filename>
</entry>
<entry>
Documentation
</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
Once OpenLDAP has been installed, next install the NetMeeting
directory kit.
Untar <filename>ndk.tgz</filename>.
It contains these files:
</para>
<table>
<title>
NetMeeting directory kit files
</title>
<tgroup cols=2>
<tbody>
<row>
<entry><filename>netmeeting.perl</filename></entry>
<entry>
Perl script used to correct NetMeeting protocol violations
</entry>
</row>
<row>
<entry><filename>netmeeting.schema</filename></entry>
<entry>
Custom NetMeeting schema used by the LDAP server
</entry>
</row>
<row>
<entry><filename>core.schema.patch</filename></entry>
<entry>
Patch to LDAP server's core schema
</entry>
</row>
<row>
<entry><filename>slapd.conf</filename></entry>
<entry>
Sample config file for the master LDAP server
</entry>
</row>
<row>
<entry><filename>slapd2.conf</filename></entry>
<entry>
Sample config file for the slave LDAP server
</entry>
</row>
<row>
<entry><filename>initialize</filename></entry>
<entry>
Shell script used once to initialize the slave LDAP database
</entry>
</row>
<row>
<entry><filename>slapd.rc</filename></entry>
<entry>
<filename class=directory>/etc/rc.d/</filename> script
</entry>
</row>
<row>
<entry><filename>nmaddentry</filename></entry>
<entry>
Perl script to add entries to the NetMeeting directory
</entry>
</row>
<row>
<entry><filename>nmdirectory</filename></entry>
<entry>
Perl/Tk script to query the NetMeeting directory
</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
Copy <filename>netmeeting.perl</filename> to the
<filename class=directory>/usr/local/libexec</filename> directory,
<filename>netmeeting.schema</filename> to the
<filename class=directory>/usr/local/etc/openldap/schema</filename>
directory,
and copy both <filename>slapd.conf</filename>
and <filename>slapd2.conf</filename> to the
<filename class=directory>/usr/local/etc/openldap</filename> directory.
</para>
<para>
Be sure to use <filename>core.schema.patch</filename> to patch
openldap's core schema in the
<filename class=directory>/usr/local/etc/openldap/schema</filename>
directory:
</para>
<screen>
bash$ <userinput>cd /usr/local/etc/openldap/schema</userinput>
bash$ <userinput>ls</userinput>
corba.schema inetorgperson.schema misc.schema nis.schema
core.schema java.schema nadf.schema openldap.schema
cosine.schema krb5-kdc.schema netmeeting.schema
bash$ <userinput>cp core.schema core.schema.bak</userinput>
bash$ <userinput>patch core.schema &lt; ~/core.schema.patch</userinput>
</screen>
<para>
Create the directory
<filename class=directory>/usr/local/var/openldap-netmeeting</filename>
to store the LDAP database, and make it world writable.
</para>
<para>
Especially if you're using directories from the samples, edit
<filename>slapd.conf</filename> and <filename>slapd2.conf</filename>
and verify their configuration settings.
</para>
<para>
You will need to run two copies of <command>slapd</command>.
One uses <filename>slapd.conf</filename>
and must be started as root, since it binds to port 389.
The <option>-u</option> option can be specified to cause
<command>slapd</command> to <function>chown</function>
to an unprivileged user after binding the port (a wise precaution).
The other <command>slapd</command>
uses <filename>slapd2.conf</filename>, binds to an unprivileged
port, and only needs
sufficient privilege to write the database directory.
</para>
<screen>
bash# <userinput>/usr/local/libexec/slapd -f /usr/local/etc/openldap/slapd.conf -u nobody</userinput>
bash$ <userinput>/usr/local/libexec/slapd -h ldap://localhost:2345/ -f /usr/local/etc/openldap/slapd2.conf</userinput>
</screen>
<para>
You now have to initialize the slave database with a single entry.
This is only done once, by running the <filename>initialize</filename>
script
included in the kit. The "rootdn" and "rootpw" entries are
in the slave config file to allow access for the initialization
script, and must match the <option>-D</option> and <option>-w</option>
options in the script.
Once you've initialized the database with a single parent
entry, you can comment out the "rootdn" and "rootpw" lines
from <filename>slapd2.conf</filename>, though this is not critical.
</para>
<para>
The server should now be up and running.
For systems with <filename class=directory>/etc/rc.d/</filename>
style initialization scripts (like RedHat),
the <filename>slapd.rc</filename> is provided to automate the
starting and stopping of the <command>slapd</command>s.
</para>
</section>
<section id="security">
<title>Server Security</title>
<para>
As shown above, I run both <command>slapd</command>s
as an unprivileged user, minimizing the possibility of compromised
security due to a bug in either the server software or the Perl
script. Of course, this requires the database directory
to be world writable so that the unprivileged slave server can
update it. This isn't as glaring a hole as it might first appear,
since the NetMeeting clients themselves use no authentication.
Thus, even if the database directory were better protected,
anyone on a local or remote host could use LDAP client
programs to delete or modify any of the database entries.
</para>
</section>
<section id="windows2000ldap">
<title>LDAP issues with Windows 2000</title>
<para>
Recent NetMeeting releases initially attempt to connect
to the LDAP directory server on port 1002. As described in a
<ulink url="http://www.microsoft.com/TechNet/chats/trans/iis1208.asp">TechNet chat</ulink>,
<blockquote><para>
Prior to Windows
2000, an ILS server would listen on port 389 for NetMeeting clients. When an
ILS server is set up on a Windows 2000 machine, it will default to port 1002.
</para></blockquote>
If a connection to port 1002 is rejected, NetMeeting will fall back
on the standard LDAP port 389. However, at least one user has reported
trouble with a firewall that blocks port 1002, discards the
connection attempts, and thus no replies are received to
reject the connection. In this case, NetMeeting takes about a minute
to timeout and fall back to port 389. Opening the firewall to
port 1002 allowed the rejects through and triggered a rapid fallback.
</para>
</section>
<section id="interoperation">
<title>Interoperation with other LDAP service</title>
<para>
The instructions above assume that your LDAP server is only
being used for NetMeeting directory service. Yet what if you
want to use a single server for both NetMeeting directory service
and other LDAP service? Only one server can be bound to port 389,
but OpenLDAP allows multiple database sections to be specified
in its configuration file, each serving different parts of the
LDAP namespace. NetMeeting uses only the "objectClass=RTPerson"
subtree, so as long as you avoid this subtree, you can configure
additional database sections to serve other subtrees with other
databases. The biggest problem you are likely to encounter is
the custom NetMeeting schema, which conflicts slightly with the
standard schema. Since the NetMeeting schema is more liberal
than the standard schema, I'd suggest commenting out the conflicting
parts of the standard schema. NetMeeting clients won't work with
the standard schema. See the LDAP RFCs and the OpenLDAP documentation
for more information about configuring LDAP servers.
</para>
</section>
</section>
<section id="using">
<title>Using the Software</title>
<section id="directconnect">
<title>Direct Connection</title>
<para>
You can use OpenH323's <command>ohphone</command>
program to connect directly to a
NetMeeting client. Specify the <option>-n</option>
option to indicate that you're
not using a gatekeeper, and either the DNS name or IP address of
the NetMeeting client:
</para>
<screen>
bash$ <userinput>ohphone -n 208.130.48.22</userinput>
</screen>
<para>
You can also start <command>ohphone</command> to receive incoming
calls from NetMeeting clients:
</para>
<screen>
bash$ <userinput>ohphone -n</userinput>
</screen>
<para>
See the <command>ohphone</command> documentation for more information
on its additional features, including video conferencing, codec
selection, and auto-answer.
</para>
</section>
<section id="diropt">
<title>Directory Operation</title>
<para>
Make sure you have an LDAP server running the NetMeeting directory kit,
as described above.
</para>
<para>
On the NetMeeting client, select the
<menuchoice>
<guimenu>
Tools
</guimenu>
<guimenuitem>
Options
</guimenuitem>
</menuchoice>
menu item to display a configuration dialog. Under the
"General" (NetMeeting 3) or "Calling" (NetMeeting 2) tab,
there will be a section for "Directory Settings".
Here you can enter the IP address or DNS name of the server.
The client will then attach to the server and register itself
either automatically, if the "Log on to directory server when
NetMeeting starts" checkbox is selected.
You can also log on to the directory server manually, by selecting
<menuchoice>
<guimenu>
Call
</guimenu>
<guimenuitem>
Log on
</guimenuitem>
</menuchoice>
.
</para>
<para>
If the user selects
<menuchoice>
<guimenu>
Call
</guimenu>
<guimenuitem>
Directory
</guimenuitem>
</menuchoice>,
a directory window will be displayed showing all users
registered on the LDAP server.
Double-clicking on one of the names will initiate a connection
to that user.
</para>
<para>
Querying the NetMeeting LDAP server from Linux can be done, but
is tricky because the client's IP address is stored in decimal,
and I don't mean dotted decimal. For example, the IP address
63.216.69.197 is stored as 3309688895. Here's some
Perl code to convert back and forth from the NetMeeting
IP address format:
</para>
<screen>
# Convert $addr (IP address or DNS name) to a NetMeeting decimal IP address
use Socket;
$bytestring = inet_aton($addr);
if (defined $bytestring) {
($sipaddress) = unpack('V', $bytestring);
} else {
die "Can't resolve $addr\n";
}
# Convert $sipaddress (from a NetMeeting LDAP server) into dotted decimal form
$packedipaddr = pack 'V', $sipaddress;
$ipaddress = join '.', unpack('C4',$packedipaddr);
</screen>
<para>
Included with the NetMeeting directory kit is
<command>nmdirectory</command>, a simple Perl/Tk script to query
a NetMeeting LDAP server and display the clients registered with it.
It's very primitive, and doesn't work well with large databases,
but provides a rudimentary example of how to interpret search
results from a NetMeeting LDAP server.
</para>
</section>
<section id="lnkfrmwebpage">
<title>Linking From A Web Page</title>
<para>
Microsoft Internet Explorer understands URLs with a "callto:" scheme
that specify NetMeeting destinations in one of two forms. When a
link with a "callto:" URL is selected, Internet Explorer runs
NetMeeting and directs it to connect to the specified destination.
</para>
<para>
The first URL form, "callto:destination", where 'destination' is
either an IP address or a DNS name, causes NetMeeting to open an
H.323 connection to port 1720 on 'destination'. Use this form
to connect directly to another NetMeeting or OpenH323 client.
</para>
<para>
The second URL form, "callto:server/alias", causes a directory lookup
on LDAP server 'server', searching for a CN attribute of 'alias'.
Assuming a match is found, a connection is made to the IP address
specified in the entry's sipAddress attribute. NetMeeting clients,
by default, register their user's E-mail addresses in the CN
attribute. Use this form to perform a directory lookup based
on E-mail address.
</para>
</section>
<section id="permdirent">
<title>Permanent Directory Entries</title>
<para>
NetMeeting clients aren't the only source of LDAP directory entries.
In particular, permanent directory entries can be manually inserted
into the LDAP server using the OpenLDAP client tools. Assuming the
attributes are specified properly, these entries will then appear in
NetMeeting directory listings and can be used as targets in "callto:"
URLs. This is useful when working with OpenH323 clients that don't
register themselves by default with the LDAP server.
</para>
<para>
To simply creating directory entries, the <command>nmaddentry</command>
script is included in the NetMeeting directory kit. Run it
without arguments for a usage message. For example, if you've
started <command>ohphone</command> on "y2k.freesoft.org", you
can register it with the LDAP server on "ils.freesoft.org" using
alias "baccala@freesoft.org" like this:
</para>
<screen>
bash$ <userinput>nmaddentry -h ils.freesoft.org baccala@freesoft.org y2k.freesoft.org</userinput>
Successfully added cn=baccala@freesoft.org, objectclass=rtperson
bash$
</screen>
<para>
This entry will now appear in NetMeeting directory listings and
can be addressed as "ils.freesoft.org/baccala@freesoft.org".
The entry will automatically timeout after 30 minutes.
The <option>-p</option> switch creates a permanent directory
listing that won't time out, but this only works on
OpenLDAP servers using the NetMeeting directory kit.
To remove a permanent entry,
use the <command>ldapdelete</command> program
included with the OpenLDAP distribution, specifying the LDAP
Distinguished Name returned by <command>nmaddentry</command>:
</para>
<screen>
bash$ <userinput>ldapdelete -h ils.freesoft.org 'cn=baccala@freesoft.org,objectclass=rtperson'</userinput>
bash$
</screen>
</section>
<section id="servmultalias">
<title>Serving Multiple Aliases</title>
<para>
The attributes registered by a NetMeeting client include 'sport',
the TCP port number it listens on for incoming H.323 requests, but
since this attribute is never retrieved in search requests, it
isn't as useful as it first appears. In fact, NetMeeting always
opens H.323 connections to the default port (1720), which raises
the question of how to serve multiple aliases from a single IP
address.
</para>
<para>
The key to doing this is the <command>forwarder</command>
program, included in the OpenH323 CVS archive.
<command>forwarder</command> listens for connections
on port 1720, and can be configured to redirect them based on the
alias being called. This allows calls for each alias to be sent to
a unique port number, where a program like <command>ohphone</command>
or <command>openam</command> is listening.
</para>
<para>
To use aliases, an LDAP directory is required, with an entry for each
alias. Each alias entry should specify a 'cn' attribute with the
alias name, and a 'sipAddress' attribute with the IP address of the
host where <command>forwarder</command> is listening.
</para>
<para>
I've successfully configured a single host to act as a combination
LDAP server (on port 389), <command>forwarder</command>
(on port 1720), and
<command>ohphone</command> and <command>openam</command>
clients on various private port numbers and remote systems.
</para>
</section>
<section id="answeringmachine">
<title>Using the Answering Machine</title>
<para>
The OpenH323 answering machine, <command>openam</command>, will
listen for incoming H.323 connections, play a pre-recorded
message, and then record any audio sent to it into a file.
It can optionally be configured to run another program at the
end of the call, to email the recorded audio, perhaps.
</para>
<para>
It's usefulness is currently (December 2000)
limited by the lack of a gatekeeper
program clever enough to redirect calls to it if there's no
answer at the main address. Thus, it will only act as an
answering machine if the <command>ohphone</command> program
is running at the main address, and has been configured to
redirect calls to another address, using
the <option>--forward-no-answer</option>
and <option>--forward-busy</option> options.
</para>
</section>
<section id="conferencecalls">
<title>Conference Calls</title>
<para>
The <command>openmcu</command> program, in the OpenH323 CVS
archive, implements an H.323 Multipoint Control Unit (MCU).
Multiple NetMeeting or <command>ohphone</command> clients
can connect to the MCU and form a conference call. As of
December 2000, the quality and reliability of the connection
is problematic, but hopefully this will improve.
</para>
</section>
<section id="natrouting">
<title>Routing Calls Through NAT</title>
<para>
Special support is required on a NAT (IP Masquerade)
router to allow H.323 traffic to pass through.
If the NAT router is running Linux, two masquerading modules
are available:
</para>
<itemizedlist>
<listitem><para><ulink url="http://www.coritel.it/coritel/ip/sofia/nat/nat2/nat2.htm">http://www.coritel.it/coritel/ip/sofia/nat/nat2/nat2.htm</ulink></para></listitem>
<listitem><para><ulink url="http://netmeetingmasq.sourceforge.net/">http://netmeetingmasq.sourceforge.net/</ulink></para></listitem>
</itemizedlist>
<note>
<para>
I have not tested either of these modules.
</para>
</note>
</section>
<section id="customconfiguration">
<title>Custom Configurations</title>
<para>
The server capabilities can be customized by modifying the
'netmeeting.perl' script. For example,
calls for stale entries could be redirected to an
"forwarder" configured to hand off to "openam" answering
machines. Thus, calls to a unavailable user would be answered
and recorded for later playback.
</para>
<para>
As OpenH323's development continues, it's expected that
these techniques will become more sophisticated, for example
by ringing the user first and only forwarding to an answering
machine if there's no answer after a given time.
Such functionality would most likely be placed in a gatekeeper.
</para>
</section>
</section>
<section id="debugging">
<title>Debugging</title>
<para>
For debugging the NetMeeting directory kit Brent Baccala suggests using
<command>ethereal</command> (<ulink url="http://ethereal.zing.org">http://ethereal.zing.org/</ulink>)
to do a packet trace. It's LDAP support is quite good. There
is also a trace file option in the Perl script "netmeeting.perl"
that can be uncommented.
</para>
<para>
You might also try running the slapds with debugging turned on
(-d 768 is a good start), but their messages are rather confusing.
</para>
<para>
For debugging H.323, try using the "-t" and "-o" options, supported
by all the OpenH323 client programs.
</para>
</section>
<appendix>
<title>LDAP attributes used by NetMeeting</title>
<para>
Distinguished Names (DNs) used by NetMeeting must always
end in "objectclass=rtperson".
The following LDAP attributes are used by NetMeeting:
</para>
<table>
<title>NetMeeting LDAP attributes</title>
<tgroup cols="2">
<tbody>
<row>
<entry>objectClass</entry>
<entry>must be "RTPerson"</entry>
</row>
<row>
<entry>cn</entry>
<entry>alias used for directory lookups; must be present</entry>
</row>
<row>
<entry>sappid</entry>
<entry>must be "ms-netmeeting"</entry>
</row>
<row>
<entry>sprotid</entry>
<entry>must be "h323"</entry>
</row>
<row>
<entry>sprotmimetype</entry>
<entry>typically "text/h323"; unused</entry>
</row>
<row>
<entry>smimetype</entry>
<entry>typically "text/iuls"; unused</entry>
</row>
<row>
<entry>sflags</entry>
<entry>must be 1</entry>
</row>
<row>
<entry>sappguid</entry>
<entry>unknown</entry>
</row>
<row>
<entry>smodop</entry>
<entry>unknown</entry>
</row>
<row>
<entry>sipaddress</entry>
<entry>decimal IP address</entry>
</row>
<row>
<entry>sport</entry>
<entry>TCP port number; unused</entry>
</row>
<row>
<entry>ssecurity</entry>
<entry>unknown</entry>
</row>
<row>
<entry>sttl</entry>
<entry>entry timeout value in minutes</entry>
</row>
<row>
<entry>c</entry>
<entry>two digit country code</entry>
</row>
<row>
<entry>rfc822mailbox</entry>
<entry>email address</entry>
</row>
<row>
<entry>givenname</entry>
<entry>optional</entry>
</row>
<row>
<entry>surname</entry>
<entry>optional</entry>
</row>
<row>
<entry>comment</entry>
<entry>optional</entry>
</row>
<row>
<entry>location</entry>
<entry>optional</entry>
</row>
<row>
<entry>ilsa39321630</entry>
<entry>1 = personal; 2 = business; 4 = adult</entry>
</row>
<row>
<entry>ilsa32833566</entry>
<entry>0 = not audio capable; 1 = audio capable</entry>
</row>
<row>
<entry>ilsa32964638</entry>
<entry>0 = not video capable; 1 = video capable</entry>
</row>
<row>
<entry>ilsa26214430</entry>
<entry>0 = not in a call; 1 = currently in a call</entry>
</row>
<row>
<entry>ilsa26279966</entry>
<entry>unknown</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
NetMeeting uses a non-standard means of refreshing dynamic entries.
The Microsoft server maintains an "sttl" attribute, which is a
time to live for the entry in minutes. A search request for
attribute "sttl" resets the timer. If the timer goes to zero,
the entry is supposed to disappear from the database. Of course,
the sttl attribute doesn't actually exist in the database, and
the client doesn't bother to give us the whole DN it wants updated,
only supplying the "cn" component in the search request.
</para>
</appendix>
<appendix>
<title>NetMeeting LDAP protocol violations</title>
<para>
As mentioned, NetMeeting violates the LDAP protocol in several ways.
For the record, NetMeeting:
</para>
<itemizedlist>
<listitem>
<para>
Doesn't structure Distinguished Names (DNs) properly
</para>
<blockquote>
<para>
NetMeeting puts the most significant elements in the DN first,
instead of last, using:
</para>
</blockquote>
<blockquote>
<screen>
C=US, O=Microsoft, CN=xxx@abc.com, OBJECTCLASS=rtperson
</screen>
</blockquote>
<blockquote>
<para>
instead of the proper formating, which is:
</para>
</blockquote>
<blockquote>
<screen>
CN=xxx@abc.com, O=Microsoft, C=US
</screen>
</blockquote>
</listitem>
<listitem>
<para>
Doesn't include the required "objectclass" attribute
</para>
<blockquote>
<para>
Instead, it tacks an "OBJECTCLASS" element to the end of the DN,
as shown above.
</para>
</blockquote>
</listitem>
<listitem>
<para>
Doesn't insert parents into the LDAP server
</para>
<blockquote>
<para>
This is a clear violation of the LDAP standard, which requires
parents to exist before children can be created. I.e, to insert
this DN:
</para>
</blockquote>
<blockquote>
<screen>
CN=xxx@abc.com, O=Microsoft, C=US
</screen>
</blockquote>
<blockquote>
<para>
this DN must already exist:
</para>
</blockquote>
<blockquote>
<screen>
O=Microsoft, C=US
</screen>
</blockquote>
<blockquote>
<para>
as must this one:
</para>
</blockquote>
<blockquote>
<screen>
C=US
</screen>
</blockquote>
</listitem>
<listitem>
<para>
Doesn't understand attribute aliases, and is therefore unable
to recognize that "sn" and "surname" refer to the same attribute.
</para>
</listitem>
<listitem>
<para>
Requires that attributes in a search request be returned in
exactly the same order they were requested, a requirement not
guaranteed by the OpenLDAP server.
</para>
</listitem>
<listitem>
<para>
Specifies "base" scope in search requests, when it really should
use "sub", since it wants a list of entries, not just one
</para>
</listitem>
<listitem>
<para>
Uses the "%" character as wildcard in search requests, instead
of the "*" character specified by the standard.
</para>
</listitem>
<listitem>
<para>
In name attributes ("surname", "givenname"),
encodes accented European characters as 8-bit ISO 8859-1,
instead of multi character UTF-8 sequences
as required by LDAP (RFCs 2252 and 2256).
</para>
</listitem>
<listitem>
<para>
Uses a non-standard means of refreshing dynamic entries.
</para>
<para>
The Microsoft server maintains an "sttl" attribute, which is a
time to live for the entry in minutes. A search request for
attribute "sttl" resets the timer. If the timer goes to zero,
the entry is supposed to disappear from the database.
NetMeeting 2 supplies an "sttl" attribute, but
NetMeeting 3 doesn't actually
create the "sttl" attribute at all. Also,
the client doesn't bother to give us the whole DN it wants updated,
only supplying the "cn" component.
</para>
</listitem>
</itemizedlist>
<para>
Windows 2000 implements a modified DNS SRV
(<ulink url="http://www.freesoft.org/CIE/RFC/Orig/rfc2782.txt">RFC 2782</ulink>),
an enhanced means of locating network servers, including LDAP.
<comment>
SRV records can be provided by the DNS server.
<ulink url="http://www.isc.org/products/BIND/">ISC Bind</ulink>
has supported SRV records since version 8.2.2.
As described in the
<ulink url="http://www.nominum.com/resources/faqs/bind-faqs.html">Bind
FAQ</ulink>, the "check-names ignore" option is required to permit
underscores in the DNS names.
</comment>
Basically, if your NetMeeting server
name is "ils.freesoft.org", Microsoft Active Directory will expect
to use a subzone called "_msdcs.ils.freesoft.org". Within this
subzone, the domain controller will be called
"dc._msdcs.ils.freesoft.org" and its LDAP SRV record will be called
"_ldap._tcp.dc._msdcs.ils.freesoft.org", as
<ulink url="http://support.microsoft.com/support/kb/articles/Q178/1/69.ASP">described</ulink>
by Microsoft. Got it? To specify the default port number (389)
on the same host, your DNS SRV entry would look something like this:
</para>
<screen>
$ORIGIN ils.freesoft.org.
_ldap._tcp.dc._msdcs IN SRV 1 1 389 ils.freesoft.org.
</screen>
<para>
I've recently (March 2001)
tested this myself, and found that it doesn't
really do much of anything. The port number appears to be
completely ignored. UDP packets are sent to port 389 on
the listed host, but the standards don't specify LDAP over UDP
and OpenLDAP doesn't support it.
</para>
</appendix>
<appendix>
<title>Interoperation with Cisco</title>
<para>
Both NetMeeting and OpenH323 can interoperate with Cisco's
voice capable routers. To successfully initiate calls from
a Cisco to an OpenH323 (i.e, Linux) client, the G.711 codec
must be explicitly specified. For example, with the following
configuration, dialing "911" on the Cisco will place a call
to a Linux system (10.1.1.1) running OpenH323:
</para>
<screen>
dial-peer voice 911 voip
destination-pattern 911
session target ipv4:10.1.1.1
codec g711ulaw
</screen>
<para>
To call from Linux to a Cisco, use <command>ohphone</command>
with a <option>number@host</option> argument. <option>number</option>
should be a phone number that's been configured on the Cisco
using a <command>dial-peer</command> statement. For example,
this will call number "111" on a Cisco (10.1.1.10):
</para>
<screen>
bash$ <userinput>ohphone -n 111@10.1.1.10</userinput>
</screen>
<para>
To call from NetMeeting to a Cisco, select the Cisco as a gateway.
To do this from NetMeeting, select
<menuchoice>
<guimenu>Tools</guimenu>
<guimenuitem>Options</guimenuitem>
</menuchoice>.
For NetMeeting 2, select
<menuchoice>
<guibutton>Audio</guibutton>
</menuchoice>, check the box labeled "Use H.323 gateway", and
enter the Cisco's DNS or IP address.
For NetMeeting 3, select
<menuchoice>
<guibutton>General</guibutton>
<guibutton>Advanced Calling...</guibutton>
</menuchoice>, check the box labeled "Use a gateway..."
(not gatekeeper) and enter the Cisco's address.
Now, you can type a phone number directly into NetMeeting's address
panel and it will be relayed to the Cisco and resolved there, using
the Cisco's configured dialing rules.
If you're using NetMeeting 2, you'll need to select
"H.323 Gateway" from the "Call using:" list when you initiate the call.
</para>
</appendix>
<appendix>
<title>Thanks</title>
<para>
Many thanks have to go to Brent Baccala, who wrote the
NetMeeting directory kit, also for his 24-hour E-mail tech support, and
encouragement. Without him I would have passed a many nights more to
set it up at my own.
</para>
</appendix>
</article>