ch04s05.html

IP_Telephony_Cookbook主要讲解的是IP电话方面的知识,对这个方面需求的读者会很有帮助

  specified, logically separated into a series of thematic categories (Basics, 
  Calls, Dial Plan, Supplementary Services, Logs, LDAP, DNS, Security, Alternate 
  Gatekeeper, Advanced). 
  <LI>Endpoints Tab: allows view and control of the currently registered 
  endpoints with details on their aliases (name and number), IP addresses and 
  online time. This Tab can be used to "predefine" endpoints, i.e. assign 
  specific aliases to endpoints that may later be used for endpoint 
  identification during authentication. 
  <LI>Services Tab: allows view and configuration of the currently declared 
  services. By default, four services exist at installation time and they are 
  not activated, since their prefix setting is null. Therefore they merely exist 
  as templates for defining basic services functionality. 
  <LI>Call Control Tab: allows view and control of the calls in progress and the 
  setting up of gatekeeper initiated calls between arbitrary endpoints, with the 
  "Make call" option, assuming the gatekeeper runs in fully routed mode (see 
  Signaling Models in this book and the Settings Tab, category Calls in the ECS 
  interface). 
  <LI>Forwarding Tab: allows set-up of forwarding rules based on source and 
  destination, for three cases: forward on busy, forward on no answer, 
  unconditional forward. 
  <LI>Hierarchy Tab: allows set-up of a parent gatekeeper in order to forward 
  Location Requests for cases of unresolved destinations. User assigned filters 
  may also be applied to specify and control the extent of the cases referred 
  upstream, to the parent gatekeeper. </LI></UL></DIV>
<P>Even though the ECS gatekeeper runs out-of-the-box, you may want to inspect 
some of its basic settings and decide whether they fit the needs of your 
application. There are three Tabs that should be at least browsed through before 
proceeding with operation. </P>
<P>Under the Settings Tab, in the category "Basic", make a note of the name of 
the gatekeeper (gatekeeper ID). Also, be aware of the setting "who can 
register", where the choices are "everyone" for no authentication control, 
"predefined endpoints only" for some authentication control and "no endpoints" 
to turn down all endpoints for maintenance reasons only. The choice between 
"dial plan v.1" and "dial plan v.2" may not be obvious, but keep in mind that 
the second option allows more flexibility in hierarchically connected gatekeeper 
environments. Once chosen, it dynamically enables extra configuration sections. 
The option for "DHCP environment" may be used for authentication control, as it 
instructs the gatekeeper to identify endpoints by previously seen IP addresses 
and H.323 aliases (names) and authenticate them based on this information. The 
last choice, "merge predefined and on-line aliases upon registration" is an 
interesting feature, because it allows the gatekeeper to apply extra aliases to 
well-known and identified endpoints. E.g. an endpoint may register with a name 
alias only, but the gatekeeper will attach an E.164 number to this endpoint as 
well. </P>
<P>Under the Settings Tab, in the category "Calls", be aware of the "routing 
mode" selection, as it varies the operation of the gatekeeper dramatically. 
"Direct" mode employs minimal communication between endpoints and gatekeeper 
(RAS messages only), while "Call set-up routing" mode forces call set-up 
messages to be routed through the gatekeeper as well (Q.931). The third mode, 
forces all previous messages, as well as call control messages to be routed 
through the gatekeeper and not directly between the endpoints. The setting of 
"accept calls" can be used for maintenance reasons to turn off all calling 
between endpoints. </P>
<P>Under the Settings Tab, in the category "Dial plan", assuming you have chosen 
dial plan version 2, you will be able to specify stripping of zone prefixes from 
destination info of incoming calls. This feature may allow a more user-friendly 
dial plan, where in-zone endpoints use shorter dial numbers for dialling and 
out-of-zone endpoints use full length dial numbers. </P>
<P>In quick passing, check the category "Logs" if you would like to enable 
logging for debugging purposes and the category "Billing" to enable usage 
statistics and accounting. Category "DNS" will allow discovery of neighbour 
gatekeepers through specially crafted DNS TXT records, but it seems to be 
compatible only with other RADVISION gatekeepers. Category "LDAP" will allow 
endpoint alias data and neighbour data to be retrieved from LDAP directory 
services, as well as LDAP-enabled endpoint authentication. </P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e3607>4.5.2.3.&nbsp;Operation</H4></DIV></DIV>
<DIV></DIV>
<P>Immediately after installation, the ECS may service endpoints, and you can 
verify this by making a couple of endpoints point to the gatekeeper for 
registration. As soon as the endpoints register, they appear at the Endpoints 
Tab. You may proceed with calling between the two endpoints by dialling from the 
one the registered aliases (name or number) of the other. The ongoing call will 
appear in the Call Control Tab. As an administrator of the gatekeeper you may 
disconnect the call, or even unregister an endpoint from the respective Tab 
sections. Logs of the gatekeeper operations may be started through the Settings 
Tab, Logs subsection and can be inspected as text files from the <TT 
class=filename>C:\Program Files\Radvision\ECS\Gatekeeper\Logs</TT> directory, 
where they are maintained and rotated, after they reach a certain size. 
</P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e3615>4.5.2.4.&nbsp;Endpoint 
authentication</H4></DIV></DIV>
<DIV></DIV>
<P>The ECS gatekeeper implements H.235 authentication, but its use is limited to 
gatekeeper-to-gatekeeper and gatekeeper-to-gateway authentication, because of 
the very limited deployment of H.235 capable endpoints. The ECS implements a 
method of storing informational data for well-known endpoints (predefined 
endpoints). This feature allows for an IP address + alias identification method 
to be implemented, but such a solution imposes restrictions to endpoint 
mobility. </P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e3620>4.5.2.5.&nbsp;Advanced features</H4></DIV></DIV>
<DIV></DIV>
<P>The ECS gatekeeper is able to support hierarchies of gatekeepers 
(child-parent relationships) in cases where many levels of prefixes must be 
supported by prefix stripping or prefix substitution. For example, a 
country-level (parent) gatekeeper may need to know all dialed destinations by 
their 12-digit number, while an organization-level (child) gatekeeper may be 
able to operate with just 4-digit numbers most of the time. In order for the 
child gatekeeper to support both long and short dial strings, it needs to 
implement prefix stripping. </P>
<P>The H.450 protocol provides the implementation framework for supporting in 
H.323 a number of features common to conventional PBX systems. The ECS 
implements the H.450 protocol specifications, thus enabling many different types 
of forwarding: forward on busy, forward on no answer, forward on reject, etc. 
These features are supported only when the gatekeeper is in the full-routing 
mode (both call and control signal routing). </P>
<P>The ECS already has support for retrieving endpoint and neighbour data from 
LDAP, but it does so in a proprietary way. New developments in LDAP-enabled 
voice-over-IP services have given rise to H.350, the standardized protocol for 
storing and retrieving user settings and preferences regarding H.323 and SIP 
services. Radvision, being an active partner in the committee that developed the 
H.350 standard (previously known as H.LDAP or CommObject), has made the 
commitment to implement it in the ECS gatekeeper. </P>
<P>Until very recently, gatekeepers used to be single points of failure for 
voice-over-IP services, as endpoints in H.323 can only be registered with one 
gatekeeper. The ECS implements a special feature called "Alternate Gatekeeper", 
where two identical ECS gatekeepers on two different nodes can act in tandem, 
providing resilience in gatekeeper services transparently to the endpoints. This 
is achieved by constant exchange of information and status checking between a 
master and a slave gatekeeper, so that the second one can assume the role of the 
first in case of failure. In this case, some of the calls in progress may be 
disconnected, but at least redialing should be successful, without requiring the 
endpoints to register to a new gatekeeper. </P></DIV></DIV>
<DIV class=sect2 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H3 class=title><A id=sec-gnugk>4.5.3.&nbsp;Using an OpenH323 Gatekeeper - GNU 
Gatekeeper</H3></DIV></DIV>
<DIV></DIV>
<P>The GNU GK is the most popular and active in development of the open-source 
gatekeeper projects that stem from the OpenH323 project efforts. Being an 
open-source effort, it benefits from availability for many different operating 
systems and from flexibility in configuring a multitude of features and 
interfaces that are not usually available in commercial products, and all these 
with no licensing cost. At the same time, its initial installation is made 
problematic by lack of quality documentation and good versioning vs. feature 
availability support, in contrast to a very active mailing list that users can 
seek help with. The GNU GK supports all three modes of routing: direct, Q.931 
routing, and both Q.931 and H.245 routing. It has only basic inter-zone routing 
features, but authentication is very flexible, with very configurable RADIUS 
support and LDAP H.350 support in the works. </P>
<P>"OpenH323 Gatekeeper - The GNU Gatekeeper Documentation" is available <A 
href="http://www.gnugk.org/h323manual.html" target=_top>here</A>.</P>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e3641>4.5.3.1.&nbsp;Installation</H4></DIV></DIV>
<DIV></DIV>
<P>Installing the GNU GK gatekeeper is not a simple task, if you decide to 
compile the source of the gatekeeper and the two libraries it requires. However, 
this may be your only option, if support of MySQL and LDAP is required, since 
the provided precompiled binaries are lacking it. To avoid compilation of the 
code please refer to the Pre-Built binaries downloads at the end of this 
section. In order to compile and build the GNU GK you will need both the PWLib 
libraries (version 1.2 or later) and the OpenH323 libraries (version 1.8 or 
later), if you are not familiar with those libraries please refer to their web 
site on how to build them. </P>
<P>These libraries are available <A href="http://www.openh323.org/code.html" 
target=_top>here</A>. See the instructions on how to compile the code available 
<A href="http://www.openh323.org/build.html" target=_top>here</A>. </P>
<P>Recommended versions of the libraries are PWLib 1.4.11 or later and Openh323 
1.11.7 or later. The order of compiling the packages is the following: </P>
<P>
<DIV class=itemizedlist>
<UL type=disc compact>
  <LI>PWLib (release + debug version)
  <LI>OpenH323
  <LI>OpenH323 test application (not needed, just to make sure everything works 
  so far)
  <LI>The GNU Gatekeeper itself</LI></UL></DIV>
<P></P>
<P>To compile the GNU gatekeeper on Unix, do a "make debug" or "make opt" in the 
gatekeeper source directory to build debug or release versions, respectively. 
Use "make both" to build both versions. Note you have to use GCC 2.95.2 or 
later. Good practice is to do a "make debugdepend" or "make optdepend" in the 
gatekeeper source directory before starting actual compilation (make debug or 
make opt). On Windows just open and compile the provided project (gk.dsw) for 
Microsoft Visual C++ 6.0 or 7.0 (Visual C++ 5.0 is too old). </P>
<P>The Gatekeeper supports MySQL and LDAP back-end interfaces (support for LDAP 
is still under development). The make scripts will look for the MySQL and 
OpenLDAP libraries in standard places, but if they are not found, you will have 
to explicitly point to their source directories by config options. If you do not 
want MySQL support, you may set the NO_MYSQL environment before making: </P><PRE class=programlisting>$ NO_MYSQL=1 make both
</PRE>
<P>To leave out LDAP support:</P><PRE class=programlisting>$ NO_LDAP=1 make both
</PRE>
<P>Or disable both with</P><PRE class=programlisting>$ NO_MYSQL=1 NO_LDAP=1 make both
</PRE>
<P>For gatekeepers with a large numbers of concurrent calls, the GNU GK has 
implemented an extended "fd_set" structure that enables the Gatekeeper to 
support thousands of concurrent calls in routed mode. To enable this feature, 
export the LARGE_FDSET environment variable to the maximum number of file 
descriptors. For example: </P><PRE class=programlisting>$ LARGE_FDSET=16384 make opt
</PRE>
<P>The GNU GK includes implementation of a Radius protocol client that enables 
registration/admission authentication and authorization using Radius servers.