ch04s05.html

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

 ! In order to accept calls from VideNet as well, 
 ! you have to make your gatekeeper well known to the VideNet
 ! hierarchy of gatekeepers (see https://videnet.unc.edu/)
 !
 zone remote videnet3 videnet 137.44.172.248 1719
 zone prefix videnet3 00*
 lrq forward-queries add-hop-count
 ! 
 ! To force endpoints to register with a specific h323-id and password
 ! you can use H.235 (few endpoints support it) or the h323-id/password
 ! mechanism that the MCM provides.
 !
 accounting
 security h323-id
 security password separator /
 !
 ! Make sure no H.323 proxy services are unintentionally used,
 ! unless proxy functionality is needed for security or QoS reasons.
 !
 no use-proxy [myzone] default inbound-to terminal
 no use-proxy [myzone] default outbound-from terminal
</PRE></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e3495>4.5.1.3.&nbsp;Operation</H4></DIV></DIV>
<DIV></DIV>
<P>Immediately after configuration, the MCM 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 can be listed with the 
following command: </P><PRE class=programlisting>&gt; show gatekeeper endpoints
</PRE>
<P>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 can 
be listed with the following command: </P><PRE class=programlisting>&gt; show h323 gatekeeper calls
</PRE>
<P>As an administrator of the gatekeeper you may disconnect the call, or even 
unregister an endpoint. </P><PRE class=programlisting>&gt; clear gatekeeper call call-id . . .
&gt; unregister . . .
</PRE>
<P>A view of the operational status of the gatekeeper, such as zones defined, 
endpoints registered, neighbour gatekeepers defined etc. may be displayed by the 
following command: </P><PRE class=programlisting>&gt; show gatekeeper status
</PRE>
<P>Debug logs of the gatekeeper operations may be monitored with the following 
sequence of commands: </P><PRE class=programlisting>&gt; terminal monitor
&gt; debug gatekeeper main 10
&gt; debug h225 asn1
&gt; debug h245 asn1
	</PRE>
<P>The first command makes your terminal capable of displaying console style 
logs and debugging output. The second command produces debugging output 
regarding basic gatekeeper actions. Obviously, the last two commands display 
info on H.225 and H.245 protocols and the output can be overwhelming, but it may 
be the only debugging option when faced with an otherwise intractable problem. 
Each debugging option can be stopped by its equivalent "no debug" and all 
debugging output can be stopped with the "no debug all" command. </P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e3520>4.5.1.4.&nbsp;Endpoint 
authentication</H4></DIV></DIV>
<DIV></DIV>
<P>The MCM 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. Cisco has implemented an 
alternative method for endpoint authentication, which allows for an H.323 or 
E.164 alias to carry (piggy-back) both alias info and a password, separated by 
an administrator defined special character, e.g. /. A configuration for this 
feature is provided above and once activated, endpoints must be configured to 
use alias/password combinations to register with the gatekeeper. There are 
shortcomings to this method and stem mostly from the fact that it is a 
proprietary solution, which in some cases exposes clear text passwords to 
neighbour devices (MCUs, gateways, gatekeepers). Of course, the MCM includes 
RADIUS support, which might allow for an IP address + alias identification 
method to be implemented on the RADIUS server side, 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=d0e3525>4.5.1.5.&nbsp;Advanced features</H4></DIV></DIV>
<DIV></DIV>
<P>The Cisco MCM supports RADIUS authentication and accounting to a remote 
RADIUS server. With the extensive support of RADIUS servers to a number of 
back-ends such as databases and directory services, this can be an important 
feature when seeking a method of integrating H.323 access control with already 
deployed services (e.g. dial-up, LDAP), or a simple way of storing 
call-accounting information in a database. Also, the exchange of standard and 
vendor-specific attributes during the RADIUS negotiation process allows very 
fine control of some delicate parameters such as "call duration" which would 
otherwise be inaccessible to an external-to-the-gatekeeper application. Of 
course, only experienced RADIUS administrators and middleware developers can 
exploit the full potential of the RADIUS configuration files and its back-end 
interfaces. The Cisco MCM supports an alternative method to neighbour discovery 
than static neighbour entries in the IOS configuration. A DNS-based gatekeeper 
discovery mechanism is in place that allows the MCM to find gatekeepers 
responsible for a specific domain by checking for the existence of a TXT record 
in the domain's DNS zone info. This can be useful if a large community of users 
in separate zones employs e-mail addresses for dialling. The gatekeepers serving 
them do not need to have static knowledge of each other, but can discover 
destination gatekeepers responsible for a domain through DNS. Multiple zone 
support is implemented on the MCM in a way that allows multiple instances of the 
gatekeeper to run within one router. This would have been an excellent feature, 
if it could have avoided a major handicap: endpoint registration to a specific 
gatekeeper has to be guided by administratively preset IP address subnet 
restrictions. Interestingly enough, Cisco gateways can utilize this 
functionality by indicating on their RRQ messages (by gatekeeper ID and not by 
IP address) which gatekeeper they request to be registered with. 
</P></DIV></DIV>
<DIV class=sect2 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H3 class=title><A id=d0e3530>4.5.2.&nbsp;Using a Radvision Enhanced 
Communication Server (ECS gatekeeper)</H3></DIV></DIV>
<DIV></DIV>
<P>The Radvision ECS is a software only gatekeeper that runs on the WinNT or 
Win2000 operating systems, a fact that ties it to specific remote management 
techniques used with all other Windows based servers. It is a commercial grade 
implementation and it is considered top-of-the-line for the features it provides 
and its compatibility even with the latest H.323 specs. It is servicing large 
organizations with a great number of endpoints and some of the VideNet global 
root gatekeepers most notably. The ECS supports all three modes of routing: 
direct, Q.931 routing, and both Q.931 and H.245 routing. The ECS has good 
interzone routing features with DNS gatekeeper discovery and neighbour 
gatekeeper LDAP support as extra. Authentication is very flexible, with ability 
for "predefined" endpoint settings enforced at registration time and LDAP H.350 
support, but no RADIUS support. </P>
<P>"ECS gatekeeper product description" is available <A 
href="http://www.radvision.com/NBU/Products/viaIP+Custom+Solutions/Gatekeeper+(ECS).htm" 
target=_top>here</A>.</P>
<P>"ECS gatekeeper specifications" are available <A 
href="http://www.radvision.com/NR/rdonlyres/7D510F55-F4EA-408C-8721-4ACA39ADDA3E/320/ECSDatasheet1.pdf" 
target=_top>here</A>.</P>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e3545>4.5.2.1.&nbsp;Installation</H4></DIV></DIV>
<DIV></DIV>
<P>Installing the ECS gatekeeper is a very simple task, since it involves merely 
the execution a GUI setup wizard, which requires no configuration options. The 
only potential source of installation problems lies with the fact that the 
Windows SNMP service must be already installed, before any service packs and the 
ECS installer are applied. If this advice, which is listed in the ECS 
documentation, is ignored, the ECS installer refuses to proceed and the only 
option is to reinstall the operating system itself. Also, the administrator of 
the host must make sure that port 80 is free, since the ECS installs an HTTP 
service on this default port for configuration management over a web interface. 
The documentation also calls for an FTP server to be running at the same host, 
but it only serves for downloading ECS log files, which is not a required 
functionality. </P></DIV>
<DIV class=sect3 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H4 class=title><A id=d0e3550>4.5.2.2.&nbsp;Configuration</H4></DIV></DIV>
<DIV></DIV>
<P>Once installed, the ECS is ready to run with default configuration options. 
The administrator can access the management interface (see <A 
title="Figure&nbsp;4.14.&nbsp;ECS local administration entry" 
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04s05.html#rv-ecs-entry">Figure&nbsp;4.14</A>) 
by launching a browser and requesting the local web server (http://localhost). 
The interface presents a login page, where the default username and password can 
be entered (admin/null-no-password). After successful login, the administrator 
is made aware of the fact that the management tool can supervise the operation 
of a whole hierarchy of ECS gatekeepers ("Global" picture), as well as the 
single ECS installation residing on this host ("Local" picture). Proceed with 
the "Local administrator" interface. </P>
<DIV class=figure><A id=rv-ecs-entry>
<P class=title><B>Figure&nbsp;4.14.&nbsp;ECS local administration entry</B></P>
<DIV class=mediaobject align=center>
<TABLE cellSpacing=0 cellPadding=0 width=283 
summary="manufactured viewport for HTML img" border=0>
  <TBODY>
  <TR>
    <TD align=middle><IMG alt="ECS local administration entry" 
      src="ch04s05.files/rv-ecs-entry.png" width=283 
align=middle></TD></TR></TBODY></TABLE></DIV></DIV>
<P>Immediately afterwards, the menus for the administration of the locally 
installed gatekeeper are shown, as below.</P>
<DIV class=figure><A id=rv-ecs-menus>
<P class=title><B>Figure&nbsp;4.15.&nbsp;ECS administration menus</B></P>
<DIV class=mediaobject align=center>
<TABLE cellSpacing=0 cellPadding=0 width=496 
summary="manufactured viewport for HTML img" border=0>
  <TBODY>
  <TR>
    <TD align=middle><IMG alt="ECS administration menus" 
      src="ch04s05.files/rv-ecs-menus.png" width=496 
align=middle></TD></TR></TBODY></TABLE></DIV></DIV>
<P>There are four commands to allow configuration management. The "Refresh" 
button fills in the web interface forms with configuration data from the 
currently running ECS gatekeeper configuration. The "Upload" button takes all 
the changes made on the web interface and applies them to the currently running 
ECS configuration. The "Import" and "Export" buttons are used to store and 
retrieve snapshots of the configuration at different points in time. </P>
<P>The rest of the interface is fairly straightforward, with an array of 
configuration Tabs (sections), the most important of which are listed below: 
</P>
<DIV class=itemizedlist>
<UL type=disc compact>
  <LI>Status Tab: allows view of the current status of the gatekeeper by 
  indicating the number of ongoing calls and registered endpoints, as well as 
  bandwidth usage statistics for in-zone and out-of-zone calls. 
  <LI>Settings Tab: this is where most of the configuration options are