Sophie

Sophie

distrib > Mandriva > 2008.0 > x86_64 > by-pkgid > 00bdf001b179ab7cab5a36ebc3f9271b > files > 155

gnugk-2.2.6-2mdv2008.0.x86_64.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
 <TITLE>OpenH323 Gatekeeper - The GNU Gatekeeper: Neighbor Configuration</TITLE>
 <LINK HREF="manual-11.html" REL=next>
 <LINK HREF="manual-9.html" REL=previous>
 <LINK HREF="manual.html#toc10" REL=contents>
</HEAD>
<BODY>
<A HREF="manual-11.html">Next</A>
<A HREF="manual-9.html">Previous</A>
<A HREF="manual.html#toc10">Contents</A>
<HR>
<H2><A NAME="s10">10.</A> <A HREF="manual.html#toc10">Neighbor Configuration</A></H2>


<H2><A NAME="neighbor"></A> <A NAME="ss10.1">10.1</A> <A HREF="manual.html#toc10.1">Section [RasSrv::Neighbors]</A>
</H2>

<P>If the destination of an ARQ is unknown, the gatekeeper sends LRQs to
its neighbors to ask if they have the destination endpoint.
A neighbor is selected if one of its prefixes matches the destination
or it has ``<CODE>*</CODE>'' prefix. More than one prefix can be specified.
You can use special characters ``<CODE>.</CODE>'' and ``<CODE>!</CODE>'' to do wildcard
matching and disable a specific prefix.</P>
<P>Conversely, the gatekeeper will only reply to LRQs sent from neighbors
defined in this section.
If you specify an empty prefix, no LRQ will be sent to that neighbor,
but the gatekeeper will accept LRQs from it. By the empty prefix it is meant
a single semicolon appended to the neighbor entry. Example:<BR><BR>
<CODE>  GK1=192.168.0.5;</CODE><BR><BR>
If you skip the semicolon, LRQs will be always sent to this neighbor.</P>
<P>The <CODE>password</CODE> field is used to authenticate LRQs from that neighbor.
See section 
<A HREF="manual-8.html#gkauth">[Gatekeeper::Auth]</A> for details.</P>
<P>If a call from a neighbor is accepted also depends on the AcceptNeighborsCalls switch in the 
<A HREF="manual-5.html#routed">[RoutedMode]</A> section.</P>
<P>Neighbor handling has changed significantly from version 2.0 to version 2.2.
Neighbors can be specified now the old or the new way.</P>
<P>
<DL>
<DT><B>Entry in the old format:</B><DD><P><CODE>GKID=ip[:port;prefixes;password;dynamic]</CODE></P>

<DT><B>Example:</B><DD><P><CODE>GK1=192.168.0.5;*</CODE><BR>
<CODE>GK2=10.0.1.1:1719;035,036;gk2</CODE><BR>
<CODE>GK3=gk.citron.com.tw;;gk3;1</CODE></P>
</DL>
</P>
<P>
<DL>
<DT><B>Entry in the new format:</B><DD><P><CODE>GKID="GnuGK" | "CiscoGK" | "ClarentGK" | "GlonetGK"</CODE></P>

<DT><B>Example:</B><DD><P><CODE>[RasSrv::Neighbors]</CODE><BR>
<CODE>GK1=CiscoGK</CODE><BR>
<CODE>GK2=GnuGK</CODE><BR><BR>
<CODE>[Neighbor::GK1]</CODE><BR>
<CODE>GatekeeperIdentifier=GK1</CODE><BR>
<CODE>Host=192.168.1.1</CODE><BR>
<CODE>SendPrefixes=02</CODE><BR>
<CODE>AcceptPrefixes=*</CODE><BR>
<CODE>ForwardLRQ=always</CODE><BR><BR>
<CODE>[Neighbor::GK2]</CODE><BR>
<CODE>GatekeeperIdentifier=GK2</CODE><BR>
<CODE>Host=192.168.1.2</CODE><BR>
<CODE>SendPrefixes=03,0048</CODE><BR>
<CODE>AcceptPrefixes=0049,001</CODE><BR>
<CODE>ForwardHopCount=2</CODE><BR>
<CODE>ForwardLRQ=depends</CODE><BR><BR></P>
</DL>
</P>
<P>The new format specifies in the <CODE>[RasSrv::Neighbors]</CODE> section only the gatekeeper types. The configuration for each neighbor is placed in a separate section.</P>


<H2><A NAME="ss10.2">10.2</A> <A HREF="manual.html#toc10.2">Section [RasSrv::LRQFeatures]</A>
</H2>

<P>Defines some features of LRQ and LCF.
<UL>
<LI><CODE>NeighborTimeout=1</CODE><BR>
Default: <CODE>2</CODE><BR>
<P>Timeout value in seconds to wait responses from neighbors.
If no response from all neighbors after timeout, the gatekeeper will
reply an ARJ to the endpoint sending the ARQ.</P>

</LI>
<LI><CODE>SendRetries=4</CODE><BR>
Default: <CODE>2</CODE><BR>
<P>Number of tries to send LRQ to neighbors.
If no response from neighbors after retries timeout, the gatekeeper will
reply an LRJ to the endpoint sending the LRQ.</P>

</LI>
<LI><CODE>ForwardHopCount=2</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>If the gatekeeper receives an LRQ that the destination is either unknown,
it may forward this message to its neighbors.
When the gatekeeper receives an LRQ and decides that the message
should be forwarded on to another gatekeeper, it first decrements
<B>hopCount</B> field of the LRQ.
If <B>hopCount</B> has reached 0, the gatekeeper shall not forward the message.
This options defines the number of gatekeepers through which an LRQ
may propagate. Note it only affects the sender of LRQ, not the forwarder.
This setting can be overridden with configuration of a particular neighbor.</P>

</LI>
<LI><CODE>AlwaysForwardLRQ=1</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>Force the gatekeeper to forward an LRQ even if there is no <B>hopCount</B>
in the LRQ. To avoid LRQ loops, you should use this option very carefully.
This option is used only for an old-style (2.0) neighbor configuration,
the new one reads the settings from a neighbor-specific config section.</P>

</LI>
<LI><CODE>AcceptForwardedLRQ=1</CODE><BR>
Default: <CODE>1</CODE><BR>
<P>Whether to accept an LRQ forwarded from neighbors.
This setting can be overridden with configuration
of a particular neighbor.</P>

</LI>
<LI><CODE>ForwardResponse=0</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>If the gatekeeper forwards received LRQ message it can decide either
to receive the LCF response or to let it travel back directly to the LRQ
originator. Set this option to 1, if the gatekeeper needs to receive LCF
messages for forwarded LRQs. This setting can be overridden with configuration
of a particular neighbor.</P>

</LI>
<LI><CODE>ForwardLRQ=always | never | depends</CODE><BR>
Default: <CODE>depends</CODE><BR>
<P>This settings determines whether the received LRQ should be forwarded
or not. <CODE>always</CODE> forwards LRQ unconditionally, <CODE>never</CODE> blocks LRQ
forwarding, <CODE>depends</CODE> tells the gatekeeper to forward LRQ only if its
hop count is greater than 1. This setting can be overridden with configuration
of a particular neighbor.</P>

</LI>
<LI><CODE>AcceptNonNeighborLRQ=1</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>Whether to accept an LRQ forwarded from parties not defined as Neighbors.
This can be used with SRV routing policy to place calls to third party GKs.
This should be used in conjuction with a LRQ Authentication policy.</P>

</LI>
<LI><CODE>AcceptNonNeighborLCF=1</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>This setting disables matching of the LRQ responder's IP address and
specified neighbor IP addresses in order to accept LCF message responses
from any IP address. This has primary importance when a
multiple level gatekeeper hierarchy is used without routed Q.931 signaling.
As a minimal security, only LRQ/LCF sequence numbers will be checked accordingly. This feature is required by the
national gatekeepers connected to the Global Dialing Scheme (GDS), see
http://commons.internet2.edu/gds.html for more information.
WARNING: Enabling receiving LCF from other than the LRQ destination IP is a significant security risk. 
Use this setting with extreme caution.</P>
</LI>
</UL>
</P>



<H3>Section [Neighbor::...]</H3>

<P>Sections starting with <CODE>[Neighbor::</CODE> are for neighbor specific configuration.</P>
<P>
<UL>
<LI><CODE>GatekeeperIdentifier=GKID</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>Gatekeeper identifier for this neighbor. If this options is not specified,
the identifier is taken from the second part of this <CODE>Neighbor::</CODE> section name.</P>

</LI>
<LI><CODE>Host=192.168.1.1</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>An IP address for this neighbor.</P>

</LI>
<LI><CODE>Password=secret</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>A password to be used to validate crypto tokens received from incoming LRQs.
<CODE>It is not yet implemented</CODE>.</P>

</LI>
<LI><CODE>Dynamic=0</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>1 means that the IP address for this neighbor can change.</P>

</LI>
<LI><CODE>SendPrefixes=004,002:=1,001:=2</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>A list of prefixes that this neighbor expects LRQs to receive for.
If '*' is specified, LRQs will always be sent to this neighbor.
A priority can be given to each prefix for each neighbor (using := syntax),
so in case of multiple LCF received from multiple neighbor, the one
with the highest priority will be selected to route the call.
One can also direct the gatekeeper to send LRQ to this neighbor
based on an alias type:<BR>
SendPrefixes=h323_ID,dialedDigits,001<BR></P>

</LI>
<LI><CODE>AcceptPrefixes=*</CODE><BR>
Default: <CODE>*</CODE><BR>
<P>A list of prefixes that the gatekeeper will accept in LRQs received
from this neighbor. If '*' is specified, all LRQs will be accepted from this neighbor.
One can also direct the gatekeeper to accept LRQ from this neighbor
based on an alias type:<BR>
AcceptPrefixes=dialedDigits<BR></P>

</LI>
<LI><CODE>ForwardHopCount=2</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>If the gatekeeper receives an LRQ that the destination is either unknown,
it may forward this message to its neighbors.
When the gatekeeper receives an LRQ and decides that the message
should be forwarded on to another gatekeeper, it first decrements
<B>hopCount</B> field of the LRQ.
If <B>hopCount</B> has reached 0, the gatekeeper shall not forward the message.
This options defines the number of gatekeepers through which an LRQ
may propagate. Note it only affects the sender of LRQ, not the forwarder.</P>

</LI>
<LI><CODE>AcceptForwardedLRQ=1</CODE><BR>
Default: <CODE>1</CODE><BR>
<P>Whether to accept an LRQ forwarded from this neighbor.</P>

</LI>
<LI><CODE>ForwardResponse=0</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>If the gatekeeper forwards received LRQ message it can decide either
to receive the LCF response or to let it travel back directly to the LRQ
originator. Set this option to 1, if the gatekeeper needs to receive LCF
messages for forwarded LRQs.</P>

</LI>
<LI><CODE>ForwardLRQ=always | never | depends</CODE><BR>
Default: <CODE>depends</CODE><BR>
<P>This settings determines whether the received LRQ should be forwarded
or not. <CODE>always</CODE> forwards LRQ unconditionally, <CODE>never</CODE> blocks LRQ
forwarding, <CODE>depends</CODE> tells the gatekeeper to forward LRQ only if its
hop count is greater than 1. This setting can be overridden with configuration
of a particular neighbor.</P>

</LI>
</UL>
</P>

<HR>
<A HREF="manual-11.html">Next</A>
<A HREF="manual-9.html">Previous</A>
<A HREF="manual.html#toc10">Contents</A>
</BODY>
</HTML>