Updated: 2004-07-27
Created: 2004-02-04
Licensing and disclaimer of warranty
This document is an incomplete draft.
Especially but not only if one has broadband access to the Internet, or even locally, voice/video/... conferencing may be useful, in that it is both convenient and cheap.
However, as in most cases, the relevant standards and the software that implements them are arguably shoddy in design, coding and documentation, and unnecessarily hard to set up and configure.
This is a little guide to do so for some of the H.323 software
out there, mostly for Linux, but also a bit about MS Windows, to
ensure interoperation. It is not quite an HOWTO
because it tries to provide insight as well as recipes, as in
general it is hard to provide recipes that just work, instead of
being mere guidelines.
I have also created a small set of sample OpenH323 and GNUGK configuration files.
To successfully set up and configure for operation H.323 software one may need several different things, for example:
H.323 is a series of related standards published by the ITU, and is largely based on the ISO family of standards.
It defines how one endpoint may discover another, call it, and transfer data.
An endpoint can be either a process on a computer or a real telephone; it can be identified with a telephone number in both cases, or with an IP address if it is a process running on a computer.
Most endpoints are terminals, or they can be gateways in which case their main role is to act as intermediaries between other endpoints.
A gatekeeper is a special type of endpoint to which other endpoints can connect to register a symbolic name or number for themselves, and usually to ask the gatekeeper to make or receive calls on their behalf. Somewhat similar to a PBX/switch in function.
A gatekeeper is usually required for calls to real telephones, in which case the gatekeeper acts as gateway. When both endpoints involved in a call with a gatekeeper in the middle are IP based, it operates as a proxy, and this for example is useful when NAT/masquerading is involved. Gatekeepers can be either peers or endpoints to other gatekeepers.
H.323 mostly applies to calls between endpoints where at least one of them is a process with an IP address. It might also be used for calls between real telephones, where at least a segment of the path (usually the longest ins some sense) is over the Internet.
These notes however are only for the case where all endpoints involved are processes with IP addresses.
In practice H.323 exists in two variants: the original one, and the somewhat modified variants that Microsoft has introduced with NetMeeting. Even if NetMeeting has been retired by Microsoft, it is still somewhat widely used. The NetMeeting variant contains some incompatible extensions or restrictions.
However, there are at least a couple of simple, small but functional freeware MS Windows applications that can be used instead of NetMeeting, and thus these notes will not mention the NetMeeting variant much, as it is possible to use the freeware alternatives instead.
First of all, the data (sound/video/...) transport protocols of H.323 are trivial; it's just RTP over UDP, and they sort of just work.
All the major difficulties arise out of endpoint discovery and call setup, especially in the complicated cases where one has firewalls, gatekeepers, and reflectors.
Setup instruction, configuration files and optiona often refer by name to the invidual standards and protocol that are part of H.323, for example:
Within H.225 there are a number of significant interactions between an endpooint (or a peer) and a gatekeeper:
GRQ
: Gatekeeper ReQuest
(connect to gatekeeper)RRQ
: Registration ReQuest
(log into gatekeeper)IRQ
: Information ReQuest
(gatekeeper queries endpoint)ARQ
: Admission ReQuest
(call another endpoint via gatekeeper)LRQ
: Location ReQuest
(ask another gatekeeper about endpoint)BRQ
: Bandwidth ReQuest
(ask gatekeeper for bandwidth change)DRQ
: Disengage ReQuest
(close call to another endpoint)URQ
: Unregister ReQuest
(log out of gatekeeper)[Password]
section the
authentication tokens on the right hand side include the alias
name, so if one wants to create multiple entries with the same
password one cannot just copy the authentication token.
ohphone
.
.ini
files, multiple
lines with the same string on the left hand side result in a
single entry with that string as key and a value which is the
concatenation of the right hand sides.
destinationInfo = 1 entries { [0]=h323_ID 3 characters { 0070 0067 0000 pg }which of course means that aliases of 1 and 2 bytes are not going to work with a correctly functioning gatekeeper like GNUGK.
h323:
URIs, but they get misprinted in the status
line.
First name
and Surname
are specified, the alias is their concatenation separated
by a space; if Gatekeeper alias
is specified,
that will be used as the second alias.
First name
or Surname
is defined, then that is the first alias, and then the
Gatekeeper alias
is used as the second alias,
unless it is the same string as the first, in which case
there is no second alias.
First name
nor Surname
are defined, then the login name is first alias, and then the
Gatekeeper alias
is used as the second alias,
unless it is the same string as the first, in which case
there is no second alias.
--username
option.
--user
option is repeated, this
does not create multiple aliases, but a single alias that is
the concatenation of the various values specified, with spaces
in between.
chrt
,
for example like this:
for p in $(pidof ohphone); do chrt -v -r -p 5 $p; done