/usr/share/doc/gnugk/manual/manual-6.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.69">
 <TITLE>The GNU Gatekeeper: Routing Configuration</TITLE>
 <LINK HREF="manual-7.html" REL=next>
 <LINK HREF="manual-5.html" REL=previous>
 <LINK HREF="manual.html#toc6" REL=contents>
</HEAD>
<BODY>
<A HREF="manual-7.html">Next</A>
<A HREF="manual-5.html">Previous</A>
<A HREF="manual.html#toc6">Contents</A>
<HR>
<H2><A NAME="s6">6.</A> <A HREF="manual.html#toc6">Routing Configuration</A></H2>

<P>The following sections in the config file can be used to configure how calls are routed.</P>
<P>For GnuGk, "routing" means that the gatekeeper must find a destination IP
for each new call.</P>
<P>For example GnuGk may need to decide where to send a
voice call given a particular E.164 destination; there may be multiple
IP-to-ISDN gateways which it may choose from for that E.164 address.</P>
<P>Routing decisions are typically made by examining the called name or number,
but GnuGk has flexibility in what it evaluates in order to successfully
route the call.</P>
<P>Each call gets passed down a chain of routing policies.
Each policy may route the call and terminate the chain or modify it and
pass it on. You can use the setting in the following sections to
specify which policies to use and modify their behavior.</P>

<H2><A NAME="routingpolicy"></A> <A NAME="ss6.1">6.1</A> <A HREF="manual.html#toc6.1">Section [RoutingPolicy] </A>
</H2>

<P>This section explains how 
<A HREF="http://www.gnugk.org/">GNU Gatekeeper</A> routing policies are configured.</P>
<P>An incoming call request can be routed using the following
methods:</P>
<P>
<UL>
<LI><CODE>explicit</CODE><BR>
<P>The destination is explicitly specified in the call to be routed.
This policy is needed for dialing by IP address.
You can define mappings for the destination IP in the
<A HREF="#routingexplicit">Routing::Explicit</A> section.</P>

</LI>
<LI><CODE>internal</CODE><BR>
<P>The classic rule; search for the destination in
RegistrationTable</P>

</LI>
<LI><CODE>parent</CODE><BR>
<P>Route the call using information sent by the parent gatekeeper in
reply to an ARQ the gatekeeper will send (only LRQs to the child will be forwarded als LRQs).
You can define your parent gatekeeper using the 
<A HREF="manual-12.html#endpoint">Endpoint</A> section.</P>

</LI>
<LI><CODE>neighbor</CODE><BR>
<P>Route the call using neighbors by exchanging LRQ messages.</P>

</LI>
<LI><CODE>dns</CODE><BR>
<P>The destination is resolved using DNS A records or IP addresses in the called alias.
This policy can be configured in the 
<A HREF="#routingdns">Routing::DNS</A> section.</P>

</LI>
<LI><CODE>sql</CODE><BR>
<P>Route calls by rewriting the called alias with a database query or send them directly to a destination IP. The database parameters are specified in the 
<A HREF="#routingsql">Routing::Sql</A> section.</P>

</LI>
<LI><CODE>ldap</CODE><BR>
<P>Route calls by looking up the called alias in an LDAP server (searching the H323ID and TelephoneNo attribute)
and send the call to the IP in the CallDestination attribute.</P>
<P>The LDAP server is configured in the 
<A HREF="manual-8.html#ldapsettings">GkLDAP::Settings</A> section and the attributes are defined in the
<A HREF="manual-8.html#ldapattributes">GkLDAP::LDAPAttributeNames</A> section.</P>

</LI>
<LI><CODE>vqueue</CODE><BR>
<P>Use the virtual queue mechanism and generate a RouteRequest
event to allow an external application to make a routing decision.</P>

</LI>
<LI><CODE>numberanalysis</CODE><BR>
<P>Provides support for overlapped digit sending for ARQ messages.
This also partially supports Setup messages (no overlapped sending
- only number length validation).</P>

</LI>
<LI><CODE>enum</CODE><BR>
<P>ENUM (RFC3761) is a method to use DNS lookups to convert
real International Direct Dialing E.164 numbers into H.323 dialing information. The default servers
are <CODE>e164.voxgratia.net</CODE>, <CODE>e164.org</CODE> and <CODE>e164.arpa</CODE>.
To specify your own list of servers use the <CODE>ENUMservers</CODE> switch in the RoutedMode section.</P>
<P>The enum policy replaces the destination with the information returned by the ENUM server, 
so you must have the appropriate routing policies to continue processing the call after the enum policy. 
You should have the srv and dns policies after the enum policy, because the new location is often 
returned in the form of 'number@gatekeeper' and the srv and dns policies are needed to resolve this.</P>
<P>Finally, keep in mind that each routing check with the enum policy requires a DNS lookup. 
To speed up your routing, make sure you resolve internal destinations before the enum policy is applied.</P>
<P>This policy can be configured in the 
<A HREF="#routingenum">Routing::ENUM</A> section.</P>
<P>Additional ENUM schemas for gateways aside from the default "E2U+h323" may be supported via
the "enum::id" Routing policy refer 
<A HREF="#routingenum">Routing::ENUM</A> section.</P>

</LI>
<LI><CODE>srv</CODE><BR>
<P>DNS SRV or H.323 Annex O allows for the routing of calls using a H.323 URI. 
Addresses can be configured as user (at) domain. H.323 URIs are stored in the 
SRV DNS records of the domain and are queried to find the destination. </P>
<P>This policy can be configured in the 
<A HREF="#routingsrv">Routing::SRV</A> section.</P>
<P>Additional SRV schemas for gateways aside from the default "h323ls._udp." and "h323cs._tcp." may be supported via
the "srv::id" Routing policy refer 
<A HREF="#routingsrv">Routing::SRV</A> section.</P>

</LI>
<LI><CODE>rds</CODE><BR>
<P>RDS Resolver Discovery Service or DDDS Dynamic Delegation Discovery Service (examples in RFC3404 sect 5.2/5.3)
This policy is a mechanism whereby domain name SRV records are hosted in central DNS servers. The 
servers are set by [RoutedMode] RDSServers and are queried in order to resolve H323+D2U NAPTR records which
contain H.323 Annex O SRV records for domains. This can be used to virtually host URL domains or 
centralize the control of SRV records. </P>
<P>This policy can be configured in the 
<A HREF="#routingrds">Routing::RDS</A> section.</P>

</LI>
<LI><CODE>forwarding</CODE><BR>
<P>This policy will perform a database lookup if calls to this destination should be forwarded.
The configuration for this policy must be in the 
<A HREF="#routingforwarding">Routing::Forwarding</A> section.</P>

</LI>
<LI><CODE>catchall</CODE><BR>
<P>This policy will route all calls that reach it to one endpoint specified in the 
<A HREF="#routingcatchall">Routing::CatchAll</A> section.
You can use it as a fallback at the end of the policy chain to route all calls which would otherwise fail.</P>

</LI>
<LI><CODE>lua</CODE><BR>
<P>This policy runs the LUA script defined in 
<A HREF="#routingcatchall">Routing::Lua</A> section to set a call destination. NOTE: This policy is still experimental and may change!</P>

</LI>
<LI><CODE>neighborsql</CODE><BR>
<P>Same as neighbor policy except the target for the LRQ messages are retrieved from a database. The database parameters are identical to the sql routing policy. </P>
</LI>
</UL>
</P>

<P>Default configuration for routing policies is as follows:
<DL>
<P>
<BLOCKQUOTE>
<CODE>[RoutingPolicy]<BR>
default=explicit,internal,parent,neighbor</CODE>
</BLOCKQUOTE>
</P>
</DL>
</P>
<P>If one policy does not match, the next policy is tried.</P>
<P>These policies can be applied to a number of routing request types and routing input data. The different types are
ARQ, LRQ, Setup and Facility (with the callForwarded reason).
There is also the general routing policy, which is a
default for the other types.</P>
<P>
<DL>
<DT><B>Example:</B><DD>
<P>
<BLOCKQUOTE>
<CODE>[RoutingPolicy]<BR>
h323_ID=dns,internal<BR>
002=neighbor,internal<BR>
Default=internal,neighbor,parent</CODE>
</BLOCKQUOTE>
</P>
</DL>
</P>
<P>When a message is received which requires a routing
decision, all calls to an alias of the h323_ID type will be
resolved using DNS. If DNS fails to resolve the alias, it is
matched against the internal registration table. If a call is
requested to an alias starting with 002, the neighbors will be checked first,
then the internal registration table. If the
requested alias is not an h323_ID or an alias starting with
002, the default policy is used by querying the internal
registration table, then the neighbors, and if those fail, the
parent.</P>
<P>Routing policies are applied to the first message of a call:
The ARQ for calls from registered endpoints,
the Setup for calls from unregistered endpoints,
the LRQ for calls from neighbors and certain Facility messages
for calls that are forwarded by GnuGk using the ForwardOnFacility feature.
You can specify different routing policies for each type of call by using the
[RoutingPolicy::OnARQ], [RoutingPolicy::OnLRQ],
[RoutingPolicy::OnSetup] and [RoutingPolicy::OnFacility] sections
using the same syntax explained above.</P>
<P>
<DL>
<DT><B>Example:</B><DD>
<P>
<BLOCKQUOTE>
<CODE>[RoutingPolicy::OnARQ]<BR>
default=numberanalysis,internal,neighbor</CODE>
</BLOCKQUOTE>
</P>
</DL>
</P>
<P>A typical ENUM routing setup would look like this:
<DL>
<DT><B>Example:</B><DD>
<P>
<BLOCKQUOTE>
<CODE>[RoutingPolicy]<BR>
default=explicit,internal,enum,srv,dns,internal,parent,neighbor</CODE>
</BLOCKQUOTE>
</P>
</DL>
</P>


<H2><A NAME="rewrite"></A> <A NAME="ss6.2">6.2</A> <A HREF="manual.html#toc6.2">Section [RasSrv::RewriteE164] </A>
</H2>

<P>This section defines the rewriting rules for dialedDigits (E.164 number).</P>
<P>
<DL>
<DT><B>Format:</B><DD>
<P><CODE>[!]original-prefix=target-prefix</CODE></P>
<P>If the number begins with <CODE>original-prefix</CODE>,
it is rewritten to <CODE>target-prefix</CODE>.
If the `<CODE>!</CODE>' flag precedes the <CODE>original-prefix</CODE>, the sense is inverted
and the target-prefix is prepended to the dialed number. Special wildcard
characters (<CODE>'.'</CODE> and <CODE>'%'</CODE>) are available.</P>
<DT><B>Example:</B><DD>
<P><CODE>08=18888</CODE></P>
<P>If you dial <CODE>08345718</CODE>, it is rewritten to <CODE>18888345718</CODE>.</P>
<DT><B>Example:</B><DD>
<P><CODE>!08=18888</CODE></P>
<P>If you dial <CODE>09345718</CODE>, it is rewritten to <CODE>1888809345718</CODE>.</P>
</DL>
</P>
<P>Option:
<UL>
<LI><CODE>Fastmatch=08</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>Only rewrite dialDigits beginning with the specified prefix.</P>
</LI>
</UL>
</P>

<H2><A NAME="rewrite"></A> <A NAME="ss6.3">6.3</A> <A HREF="manual.html#toc6.3">Section [RasSrv::RewriteAlias] </A>
</H2>

<P>This section defines the rewriting rules for aliases. This can be used to
map gatekeeper assigned aliases to registered endpoints.</P>
<P>
<DL>
<DT><B>Format:</B><DD>
<P><CODE>[!]original-alias=target-alias</CODE></P>
<P>If the alias is <CODE>original-alias</CODE>,
it is rewritten to <CODE>target-alias</CODE>.</P>
<DT><B>Example:</B><DD>
<P><CODE>bill=033123456</CODE></P>
</DL>
</P>


<H2><A NAME="gwrewrite"></A> <A NAME="ss6.4">6.4</A> <A HREF="manual.html#toc6.4">Section [RasSrv::GWRewriteE164] </A>
</H2>

<P>This section describes rewriting the dialedDigits E.164 number depending on
the gateway a call has come from or is being sent to. This allows for more
flexible manipulation of the dialedDigits for routing etc.</P>
<P>Despite the name of the section, you can not only rewrite calls from and to gateways,
but also calls from terminals (regular endpoints) and neighbor gatekeepers.</P>
<P>In combination
with the 
<A HREF="#rewrite">RasSrv::RewriteE164</A> you can have triple
stage rewriting:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
Call from "gw1", dialedDigits 0867822
                |
                |
                V
Input rules for "gw1", dialedDigits now 550867822
                |
                |
                V
Global rules, dialedDigits now 440867822
                |
                |
                V
Gateway selection, dialedDigits now 440867822, outbound gateway "gw2"
                |
                |
                V
Output rules for "gw2", dialedDigits now 0867822
                |
                |
                V
Call to "gw2", dialedDigits 0867822
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>
<DL>
<DT><B>Format:</B><DD>
<P><CODE>alias=in|out=[!]original-prefix=target-prefix[;in|out...]</CODE></P>
<P>If the call matches the alias, the direction and begins with
<CODE>original-prefix</CODE> it is rewritten to <CODE>target-prefix</CODE>.
If the `<CODE>!</CODE>' flag precedes the <CODE>original-prefix</CODE>, the sense is inverted.
Special wildcard characters (<CODE>'.'</CODE> and <CODE>'%'</CODE>) are available.
'.' matches one character and '%' matches any number of characters.
Multiple rules for the same gateway are separated by ';'.</P>
<P>To convert dialed digits into post dial digits that are sent to the
remote side after the call connects as UserInputIndications,
use 'I' (for Input) on the prefix side and 'P' (for Postdial) on the target side.
Please note that H.245 routing through the gatekeeper must be active to send post dial digits.</P>
<P>Calls from and to gateways and terminals are matched by their first alias.
Calls from and to neighbors are matched by the neighbor ID in the GnuGk
config (the XXX in the [Neighbor::XXX] section name) or the gatekeeper identifier
of the neighbor if it is set.</P>
<P>Note that when you have multi-homed neighbors or are accepting non-neighbor LRQs,
the source of the call can not always be determined and no IN rule for a neighbor will match.
In these cases you should only use OUT and [RasSrv::RewriteE164] rules.</P>

<DT><B>Example:</B><DD>
<P><CODE>gw1=in=123=321</CODE></P>
<P>If a call is received from "gw1" to <CODE>12377897</CODE>, it is rewritten to <CODE>32177897</CODE>
before further action is taken.</P>

<DT><B>Post Dial Example:</B><DD>
<P><CODE>gw1=out=09III=09PPP</CODE></P>
<P>If a call is sent out through "gw1" to <CODE>09123</CODE>, it is rewritten to <CODE>09</CODE>
and <CODE>123</CODE> are sent as post dial digits.</P>

<DT><B>Neighbor Example 1:</B><DD>
<P>In this example the neighbor is identified by its ID and incoming calls from NbGk
will have their 01 prefix replaced by a 04 prefix.  Outgoing calls will have 04 replaced with 01.
<BLOCKQUOTE><CODE>
<PRE>
[RasSrv::Neighbors]
NbGk=GnuGk

[Neighbor::NbGk]
GatekeeperIdentifier=GK-PW-Prox
Host=192.168.1.100
SendPrefixes=*
AcceptPrefixes=*

[RasSrv::GWRewriteE164]
NbGk=in=01=04;out=04=01
</PRE>
</CODE></BLOCKQUOTE>
</P>

<DT><B>Neighbor Example 2:</B><DD>
<P>In this example the neighbor is identified by its gatekeeper identifier and
incoming calls from GK-PW-Prox that don't have a 0049 prefix get the prefix
prepended.  A call to "1234" would be rewritten to "00491234", while a call
to "00496789" would proceed unchanged because the "If incoming does not
start with 0049 and any number of digits after 0049, then prepend 0049"
logic would be false (because we already have 0049 at the beginning.)</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[RasSrv::Neighbors]
NbGk=GnuGk

[Neighbor::NbGk]
GatekeeperIdentifier=GK-PW-Prox
Host=192.168.1.100
SendPrefixes=*
AcceptPrefixes=*

[RasSrv::GWRewriteE164]
GK-PW-Prox=in=!0049.=0049.
</PRE>
</CODE></BLOCKQUOTE>
</P>
</DL>
</P>


<H2><A NAME="ss6.5">6.5</A> <A HREF="manual.html#toc6.5">Section [Endpoint::RewriteE164]</A>
</H2>

<P>Once you specify prefix(es) for your gatekeeper endpoint, the parent
gatekeeper will route calls with <B>dialedDigits</B> beginning with that prefixes.
The child gatekeeper can rewrite the destination according to the rules
specified in this section. By contrast, when an internal endpoint calls
an endpoint registered to the parent gatekeeper, the source will be
rewritten reversely.</P>
<P>
<DL>
<DT><B>Format:</B><DD>
<P><CODE>external prefix=internal prefix</CODE></P>
</DL>
</P>
<P>For example, if you have the following configuration,</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
                        [Parent GK]
                        ID=MasterGK
                        /         \
                       /           \
                      /             \
                     /               \
                [Child GK]          [EP3]
                ID=ProxyGK          E164=18888200
                Prefix=188886
                /       \
               /         \
              /           \
           [EP1]         [EP2]
           E164=601      E164=602
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>With this rule:
<BLOCKQUOTE><CODE>
<PRE>
188886=6
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>When EP1 calls EP3 by <CODE>18888200</CODE>, the CallingPartyNumber in the Q.931 Setup
will be rewritten to <CODE>18888601</CODE>. Conversely, EP3 can reach EP1 and EP2
by calling <CODE>18888601</CODE> and <CODE>18888602</CODE>, respectively. In consequence, an
endpoint registered to the child gatekeeper with prefix '<CODE>6</CODE>' will appear
as an endpoint with prefix '<CODE>188886</CODE>', for endpoints registered to
the parent gatekeeper.</P>
<P>The section does not relate to the section
<A HREF="#rewrite">RasSrv::RewriteE164</A>,
though the latter will take effect first.</P>


<H2><A NAME="routingdns"></A> <A NAME="ss6.6">6.6</A> <A HREF="manual.html#toc6.6">Section [Routing::DNS] </A>
</H2>

<P>
<UL>
<LI><CODE>ResolveNonLocalLRQ=0</CODE><BR>
Default: <CODE>1</CODE><BR>
<P>This switch determines whether the DNS policy should resolve hostnames or IPs in LRQs that don't terminate locally.</P>
</LI>
</UL>
</P>


<H2><A NAME="routingenum"></A> <A NAME="ss6.7">6.7</A> <A HREF="manual.html#toc6.7">Section [Routing::ENUM] </A>
</H2>

<P>
<UL>
<LI><CODE>ResolveLRQ=1</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>This switch toggles whether the 'enum' policy should resolve LRQs.</P>
</LI>
</UL>
</P>
<P>Additional ENUM schemas may be configured by the [Routing::ENUM::id] 
<DL>
<DT><B>Format:</B><DD>
<P><CODE>&lt;enum schema&gt;=&lt;protocol gateway&gt;</CODE></P>
</DL>
</P>
<P>
<DL>
<DT><B>Example:</B><DD>
<P>
<BLOCKQUOTE>
<CODE>[Routing::ENUM::2]<BR>
E2U+xmpp=mygateway@mydomain.com</CODE>
</BLOCKQUOTE>
</P>
</DL>
</P>


<H2><A NAME="routingsrv"></A> <A NAME="ss6.8">6.8</A> <A HREF="manual.html#toc6.8">Section [Routing::SRV] </A>
</H2>

<P>
<UL>
<LI><CODE>ResolveNonLocalLRQ=1</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>This switch selects if the 'srv' policy should resolve hostnames in LRQs that don't terminate locally.</P>
</LI>
</UL>
</P>
<P>Additional SRV schemas may be configured by the [Routing::SRV::id] 
<DL>
<DT><B>Format:</B><DD>
<P><CODE>&lt;SRV schema&gt;=&lt;protocol gateway&gt;[;default schema port]</CODE></P>
</DL>
</P>
<P>
<DL>
<DT><B>Example:</B><DD>
<P>
<BLOCKQUOTE>
<CODE>[Routing::SRV::2]<BR>
_xmpp-server._tcp=mygateway@mydomain.com</CODE>
</BLOCKQUOTE>
</P>
</DL>
</P>

<H2><A NAME="routingrds"></A> <A NAME="ss6.9">6.9</A> <A HREF="manual.html#toc6.9">Section [Routing::RDS] </A>
</H2>

<P>
<UL>
<LI><CODE>ResolveLRQ=1</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>This switch selects if the 'rds' policy should resolve hostnames in LRQs.</P>
</LI>
</UL>
</P>


<H2><A NAME="routingexplicit"></A> <A NAME="ss6.10">6.10</A> <A HREF="manual.html#toc6.10">Section [Routing::Explicit] </A>
</H2>

<P>You can define a mapping where calls to certain IPs should be routed by the 'explicit' policy.
The new destination can either be another IP or an alias destination of any type.
If you rewrite the destination to something other than an IP, make sure you have other
routing policies in the chain behind the 'explicit' policy that can handle the new destination.</P>
<P>
<DL>
<DT><B>Format:</B><DD>
<P><CODE>IP=newIP[:port] | E.164 | alias</CODE></P>
</DL>
</P>
<P>
<DL>
<DT><B>Example:</B><DD>
<P>
<BLOCKQUOTE>
<CODE>[Routing::Explicit]<BR>
192.168.1.100=10.10.1.100<BR>
192.168.1.101=10.10.1.101:1720<BR>
192.168.1.102=654251<BR>
192.168.1.103=peter<BR>
192.168.1.104=joe@company.com</CODE>
</BLOCKQUOTE>
</P>
</DL>
</P>


<H2><A NAME="routingsql"></A> <A NAME="ss6.11">6.11</A> <A HREF="manual.html#toc6.11">Section [Routing::Sql] </A>
</H2>

<P>Rewrite the called alias with a SQL query.
Supports routing OnARQ, OnLRQ and OnSetup.</P>
<P>If the string returned from the database is 'REJECT' (upper or lower case),
the call is rejected. If the string matches a dotted IP address, it is
taken as destination IP otherwise it is treated as a new destination alias.
If 2 columns are returned, the first is treated as the new destination alias
and the second is treated as new destination IP.
If the 2nd column contains 'IGNORE', the database result is treated as if it would
only contain 1 result column. (This allows simpler SQL queries in some cases.)</P>
<P>If multiple rows of destination IPs are returned they are used as alternative routes
for failover and GnuGk will try them in order.</P>
<P>When at least one destination IP is specified or the call is rejected,
the SQL policy will end the routing chain.
If only the alias is changed, the chain continues with this updated alias.</P>
<P>When rejecting a call, the 2nd column can contain an integer designating the
reject reason (H.225 AdmissionRejectReason for registered calls,
H.225 LocationRejectReason for neighbor calls,
H.225 disconnect reason for unregistered calls).</P>
<P>If the database returns nothing, the call is passed on unchanged.</P>
<P>Use the 
<A HREF="manual-4.html#database">common database configuration options</A>
to define your database connection for this module.</P>
<P>
<UL>
<LI><CODE>Query=SELECT ...</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>Define a SQL query to fetch the new destination number.
The query is parameterized - that means parameter
replacement is made before each query is executed. The following parameters are defined:
<UL>
<LI><CODE>%c</CODE> - the called alias</LI>
<LI><CODE>%p</CODE> - the called IP (only available on Setup, empty otherwise)</LI>
<LI><CODE>%s</CODE> - the calling IP</LI>
<LI><CODE>%r</CODE> - the calling aliases</LI>
<LI><CODE>%{Calling-Station-Id}</CODE> - the calling station ID (same value as used in accounting and authentication events)</LI>
<LI><CODE>%i</CODE> - the call ID</LI>
<LI><CODE>%m</CODE> - the message type (ARQ, LRQ or Setup)</LI>
<LI><CODE>%{client-auth-id}</CODE> - a 64 bit integer ID provided to GnuGk when authenticating the call (through SQLAuth)</LI>
</UL>

Some of these can be empty if they aren't included in the ARQ, LRQ or Setup message.</P>
<P>If the query returns no rows, the current alias is used.
Otherwise, the first result row is used.</P>
<P>Query string examples.  Note that these are examples; the actual structure and schema
are user defined, as are the various field names in these examples.  GnuGk is simply expecting either IP addresses or aliases as a result of the query.</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
SELECT destination FROM routes WHERE called = '%c'
SELECT concat(prefix,'%c') FROM routes WHERE prefix = LEFT('%c', 5)
SELECT gatewayip FROM routes WHERE prefix = LEFT('%c',5)
SELECT concat(prefix,'%c'), gatewayip FROM routes WHERE route = LEFT('%c', 5) limit 3
</PRE>
</CODE></BLOCKQUOTE>
</P>

</LI>
<LI><CODE>EnableRegexRewrite=1</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>Enable basic regex rewriting where parts of the original called alias
are inserted into the result of the database query.</P>
<P>Regular expressions:</P>
<P>
<UL>
<LI>{\1} - all of the original called alias</LI>
<LI>{^\d(4)} - first 4 digits</LI>
<LI>{\d(4)$} - last 4 digits</LI>
</UL>
</P>
<P>Examples:</P>
<P>Assuming the called alias was "12345678" and the database returns
"{\1}@my.com" then all character are inserted so the new destination is "1234578@my.com".</P>
<P>If the database returns "{^\d(4)}@my.com" the first 4 digits are inserted so the new destination is "1234@my.com" and with "{\d(4)$}@my.com" from the database, the call is sent to "4578@my.com".</P>
</LI>
</UL>
</P>


<H2><A NAME="neighborsql"></A> <A NAME="ss6.12">6.12</A> <A HREF="manual.html#toc6.12">Section [Routing::NeighborSql] </A>
</H2>

<P>Select which neighbor to query for a call with a database query.</P>
<P>Use the 
<A HREF="manual-4.html#database">common database configuration options</A>
to define your database connection for this module.</P>
<P>
<UL>
<LI><CODE>Query=SELECT ...</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>Define a SQL query to fetch the new neighbor IP and port.</P>
</LI>
</UL>
</P>


<H2><A NAME="numberanalysis"></A> <A NAME="ss6.13">6.13</A> <A HREF="manual.html#toc6.13">Section [Routing::NumberAnalysis] </A>
</H2>

<P>This section defines rules for the <CODE>numberanalysis</CODE> routing policy.
The policy checks a dialed number for minimum and/or maximum number of digits
and sends ARJ, if necessary (number of digits is out of range), to support
overlapped digit sending. It also partially supports Setup messages (no overlapped sending
- only number length validation).</P>
<P>
<DL>
<DT><B>Format:</B><DD>
<P><CODE>prefix=MIN_DIGITS[:MAX_DIGITS]</CODE></P>
<P>If the number matches the <CODE>prefix</CODE>, it is verified to consist of at least
<CODE>MIN_DIGITS</CODE> digits and (if MAX_DIGITS is present) at most <CODE>MAX_DIGITS</CODE>
digits. Special wildcard characters (<CODE>!</CODE>, <CODE>'.'</CODE> and <CODE>'%'</CODE>) are available.
If the number is too short, an ARJ is send with <CODE>rejectReason</CODE> set to <CODE>incompleteAddress</CODE>.
If the number is too long, an ARJ is send with <CODE>rejectReason</CODE> set to <CODE>undefinedReason</CODE>.
Prefix list is searched from the longest to the shortest prefix for a match.
For Setup messages, a Release Complete with "badFormatAddress" is sent when the number
has an incorrect length.</P>

<DT><B>Example:</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[RoutingPolicy::OnARQ]
default=numberanalysis,internal

[Routing::NumberAnalysis]
0048=12
48=10
.=6:20
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Calls to destinations starting with 0048 require at least 12 digits,
to 48 we require 10 digits and to all other destinations at least 6 and at most 20 digits.</P>
</DL>
</P>


<H2><A NAME="routingforwarding"></A> <A NAME="ss6.14">6.14</A> <A HREF="manual.html#toc6.14">Section [Routing::Forwarding] </A>
</H2>

<P>This routing policy performs a database lookup if calls to an endpoint
should be forwarded to another endpoint.
It supports routing OnARQ, OnSetup and OnLRQ.</P>
<P>There are different types of forwards:
<UL>
<LI><B>Call Forwarding Unconditional</B> (CFU, code 1): Calls are always forwarded.</LI>
<LI><B>Call Forwarding on Busy</B> (CFB, code 2): Calls are forwarded if the called endpoint is already in a call.</LI>
<LI><B>Call Forwarding on No Answer</B> (CFNA, code 3): Calls are forwarded if the called endpoint doesn't answer the call within the AlertingTimeout.</LI>
<LI><B>Call Forwarding on Error</B> (CFE, code 4): Calls are forwarded if there is an error routing the call to the endpoint. Currently this behaves like Call Forwarding on No Answer and only one of them should be defined.</LI>
</UL>
</P>
<P>The destination where calls are forwarded to should either be aliases of local endpoints (incl. permanent endpoints) or IP numbers.
For local aliases, GnuGk will check if the destination also has forwarding configured and take it into account.</P>
<P>Use the 
<A HREF="manual-4.html#database">common database configuration options</A>
to define your database connection for this module.</P>
<P>Specifically for this module, you can specify a query to read the forwarding rules:
<UL>
<LI><CODE>Query=SELECT ...</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>Define a SQL query to fetch the forwarding rules.
The query must return 2 colums: First the code for the forwarding type and second the new destination.
It must ensure that the results are ordered ascending by forwarding code.</P>
<P>The query is parameterized - that means parameter
replacement is made before each query is executed. The following parameters are defined:
<UL>
<LI><CODE>%c</CODE> - the called alias</LI>
<LI><CODE>%p</CODE> - the called IP (only available on Setup, empty otherwise)</LI>
<LI><CODE>%s</CODE> - the calling IP</LI>
<LI><CODE>%r</CODE> - the calling aliases</LI>
<LI><CODE>%{Calling-Station-Id}</CODE> - the calling station ID (same value as used in accounting and authentication events)</LI>
<LI><CODE>%i</CODE> - the call ID</LI>
<LI><CODE>%m</CODE> - the message type (ARQ or Setup)</LI>
<LI><CODE>%{client-auth-id}</CODE> - a 64 bit integer ID provided to GnuGk when authenticating the call (through SQLAuth)</LI>
</UL>

Some of these can be empty if they aren't included in the ARQ or Setup message.
In most cases you should only use the called alias in the SQL query,
since they apply only to the incoming call and won't change when looking up chained forwarding rules.</P>

</LI>
</UL>
</P>
<P>
<DL>
<DT><B>Example:</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[RoutedMode]
GKRouted=1
AcceptUnregisteredCalls=1
; failover must be on for forward on timeout
ActivateFailover=1
FailoverCauses=1-15,17-127
DisableRetryChecks=1
; 10 sec alerting timeout (for forward on no answer)
AlertingTimeout=10000

[RoutingPolicy]
default=explicit,forwarding,internal,neighbor,explicit

[Routing::Forwarding]
Driver=MySQL
Host=localhost
Database=gnugk
Username=gnugk
Password=secret
Query=SELECT forwardtype, destination FROM forwards WHERE called = '%c' order by forwardtype asc
MinPoolSize=1
</PRE>
</CODE></BLOCKQUOTE>
</P>

<DT><B>Sample MySQL Schema:</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
create table gnugk.forwards (
    called varchar(30) not null,
    forwardtype smallint not null,
    destination varchar(30) not null default "",
    PRIMARY KEY (called, forwardtype)
);
</PRE>
</CODE></BLOCKQUOTE>
</P>

<DT><B>Sample Forwarding Rules:</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
"1234", 1, "2000"
"5678", 2, "4000"
"5678", 3, "4000"
"9876", 4, "5000"
</PRE>
</CODE></BLOCKQUOTE>
</P>

</DL>
</P>


<H2><A NAME="routingcatchall"></A> <A NAME="ss6.15">6.15</A> <A HREF="manual.html#toc6.15">Section [Routing::CatchAll] </A>
</H2>

<P>
<UL>
<LI><CODE>CatchAllIP=1.2.3.4</CODE><BR>
Default: <CODE>(empty)</CODE><BR>
<P>Specify an IP address to route all calls to. This overrides CatchAllAlias.</P>

</LI>
<LI><CODE>CatchAllAlias=Frank</CODE><BR>
Default: <CODE>catchall</CODE><BR>
<P>If CatchAllIP is not specified, then route all calls to this alias.</P>
</LI>
</UL>
</P>

<H2><A NAME="routinglua"></A> <A NAME="ss6.16">6.16</A> <A HREF="manual.html#toc6.16">Section [Routing::Lua] </A>
</H2>

<P>NOTE: This policy is still experimental and may change in the next release.
Please contact the GNU Gatekeeper authors if you want to use it in production.</P>
<P>The LUA script has the following <B>input variables</B> available:
<UL>
<LI>source - source IP</LI>
<LI>calledAlias - called alias (only first alias)</LI>
<LI>calledIP - called IP address if IP dialing was used</LI>
<LI>caller - aliasses of the caller</LI>
<LI>callingStationId - calling station ID</LI>
<LI>callid - the call ID</LI>
<LI>messageType - the message that triggered the routing process ('ARQ', 'LRQ', 'Setup' or 'Facility')</LI>
<LI>clientauthid - client auth ID</LI>
</UL>
</P>
<P>The LUA script can set these <B>output variables</B> to specify a routing destination:
<UL>
<LI>action - set this to either 'SKIP' or 'REJECT' if you don' want to route the call, otherwise the call is routed to destAlias or destIp (see below)</LI>
<LI>rejectCode - reject reason to use with 'REJECT'</LI>
<LI>destAlias - call destination alias</LI>
<LI>destIP - call destination IP</LI>
</UL>
</P>
<P>To access external resources, LUA scripts can use LUA libraries, eg. LuaSocket.</P>
<P>
<UL>
<LI><CODE>Script=destAlias=string.gsub(calledAlias, "#", "*")</CODE><BR>
Default: <CODE>(empty)</CODE><BR>
<P>Define the LUA script to run, right in the config file.</P>

</LI>
<LI><CODE>ScriptFile=script.lua</CODE><BR>
Default: <CODE>(empty)</CODE><BR>
<P>Specify a file with a LUA script to run for the 'lua' policy.</P>

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



<H2><A NAME="clirewrite"></A> <A NAME="ss6.17">6.17</A> <A HREF="manual.html#toc6.17">Section [RewriteCLI] </A>
</H2>

<P>This section contains a set of rewrite rules for ANI/CLI/H.323_ID numbers (Caller ID).
The rewrite process is done in two stages - inbound rewrite and outbound rewrite.
The inbound rewrite is done before any other Q.931 Setup message processing
(such as inbound GWRewrite, authentication, accounting, ...), and because it alters the Calling-Station-Id it will have
an effect in the authorization and accounting modules.
The outbound rewrite takes place just before the Setup message is to be forwarded
and its effect is visible only to the callee.</P>
<P>An inbound rewrite rule can be matched by a caller's IP and a dialed number
or an original CLI/ANI.
An outbound rewrite rule can be matched by a caller's IP, callee's IP and
a dialed number or a destination number (the dialed number after rewrite)
or a CLI/ANI (after inbound rewrite).</P>
<P>This module also provides CLIR (Calling Line Identification Restriction)
feature that can be configured for each endpoint (rule).</P>
<P>
<UL>
<LI><CODE>ProcessSourceAddress=1</CODE><BR>
Default: <CODE>1</CODE><BR>
<P>In addition to rewriting a Calling-Party-Number Information Element ("IE"), the sourceAddress
element of a H.225.0 Setup message can be rewritten, so both contain
consistent information.</P>

</LI>
<LI><CODE>RemoveH323Id=1</CODE><BR>
Default: <CODE>1</CODE><BR>
<P>When a sourceInfo element of an H.225.0 Setup message is rewritten,
aliases of type H323_ID, email_ID and url_ID can be left untouched
if this option is disabled.</P>

</LI>
<LI><CODE>CLIRPolicy=apply</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>A global Presentation Indicator ("PI") processing policy can be set up.
This policy will be applied to all CLI rewrite rules that do not override it.
Possible choices are <CODE>forward</CODE> - just forward the received PI as-is,
<CODE>apply</CODE> - examine the received PI and hide CLI if it is set to "presentation
restricted" and <CODE>applyforterminals</CODE> - similar to <CODE>apply</CODE> except that the number
is removed only when the call is sent to a terminal, not a gateway.</P>

</LI>
</UL>
</P>
<P>
<DL>
<DT><B>Format for an inbound rule:</B><DD>
<P><CODE>in:CALLER_IP=[pi=[allow|restrict][,forward|apply|applyforterminals]] [cli:|dno:]number_prefix(=|*=|~=|^=|/=)NEW_CLI[,NEW_CLI]...</CODE></P>
<P>The <CODE>in:</CODE> prefix specifies that this is an inbound rule and the <CODE>CALLER_IP</CODE>
will be used to match the rule (it can be a single IP or an entire subnet).
You can use IPv4 or IPv6 addresses for the <CODE>CALLER_IP</CODE>.<BR></P>
<P>The optional <CODE>pi=</CODE> parameter controls CLIR (Calling Line Identification Restriction)
features. Specifying either <CODE>allow</CODE> or <CODE>restrict</CODE> forces presentation indicator
to be set to "presentation allowed" or "presentation restricted". <CODE>forward</CODE>, <CODE>apply</CODE>
and <CODE>applyforterminals</CODE> controls how the received (if any) presentation indicator
is processed by the gatekeeper. <CODE>forward</CODE> means forward it to the callee as-is,
<CODE>apply</CODE> is used to hide the CLI if the PI is set to "presentation restricted", <CODE>applyforterminals</CODE>
is similar to <CODE>apply</CODE>, except that CLI is hidden only when sending the call to a terminal,
not a gateway.<BR></P>
<P>The prefix <CODE>cli:</CODE> or <CODE>dno:</CODE> (the default) selects what number will be used
to match the <CODE>number_prefix</CODE> - a caller id (CLI/ANI) or a dialed number.
Number matching/rewriting can be done in five ways:
<UL>
<LI><CODE>=</CODE> - a <CODE>cli</CODE> or <CODE>dno</CODE> number will be matched using a prefix
match against <CODE>number_prefix</CODE> and, if the match is found,
CLI will be replaced with NEW_CLI.</LI>
<LI><CODE>~=</CODE> - a <CODE>cli</CODE> or <CODE>dno</CODE> number will be matched using an identity
match against <CODE>number_prefix</CODE> and, if both numbers are the same,
CLI will be replaced with NEW_CLI.</LI>
<LI><CODE>*=</CODE> - (VALID ONLY FOR <CODE>cli</CODE>) a <CODE>cli</CODE> number will be matched using
a prefix match against <CODE>number_prefix</CODE> and, if the match is found,
the matched CLI prefix (<CODE>number_prefix</CODE>) will be replaced
with a NEW_CLI prefix.</LI>
<LI><CODE>^=</CODE> - a <CODE>cli</CODE> or <CODE>dno</CODE> number will be matched using a prefix
match against <CODE>number_prefix</CODE> and, if the match is found,
H.323_ID will be replaced with NEW_CLI, Calling-Station-Id will remain unchanged.</LI>
<LI><CODE>/=</CODE> - a <CODE>cli</CODE> or <CODE>dno</CODE> number will be matched using an identity
match against <CODE>number_prefix</CODE> and, if both numbers are the same,
H.323_ID will be replaced with NEW_CLI, Calling-Station=Id will remain unchanged,</LI>
</UL>

After the equality (=/&nbsp;=/*=/^=//=) sign, there follows a list of new CLI values to be used.
If more than one value is specified, one will be chosen on a random basis.
It's possible to specify whole number ranges, like 49173600000-49173699999
(for number ranges CLIs should have a fixed length).
There is a special string constant "any" which may be used in place
of the <CODE>CALLER_IP</CODE> or the <CODE>number_prefix</CODE>. To enable <CODE>CLIR</CODE> for this rule,
use the special string constant <CODE>"hide"</CODE> instead of the list of new CLI values.
Note that CLIR is far more useful for outbound rules.</P>

<DT><B>Example 1:</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[RewriteCLI]
in:192.168.1.1=dno:5551=3003
in:192.168.1.1=cli:1001=2222
in:192.168.1.1=any=1111
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>These rules state that for calls from the IP 192.168.1.1:
1) if the user dialed a number beginning with 5551, set CLI to 3003,
2) if the call is from user with CLI beginning with 1001, set CLI to 2222,
3) for other calls from this IP, set CLI to 1111.</P>

<DT><B>Example 2:</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[RewriteCLI]
in:192.168.1.0/24=any=18001111
in:192.168.2.0/24=any=18002222
in:2002:4ad0:ff00:79a::2/64=any=18003333
in:any=any=0
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>These rules state that:
1) for calls from the network 192.168.1.0/24, set CLI to 18001111,
2) for calls from the network 192.168.2.0/24, set CLI to 18002222,
3) for calls from the network 2002:4ad0:ff00:79a::2/64, set CLI to 18003333,
4) for other calls, set CLI to 0.</P>

<DT><B>Example 3:</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[RewriteCLI]
in:192.168.1.0/24=0048*=48
in:192.168.1.0/24=0*=48
in:any=100.~=48900900900
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>These rules state that:
1) for calls from the network 192.168.1.0/24, rewrite 0048 to 48 (example - 0048900900900 => 48900900900),
2) for other calls from the network 192.168.1.0/24, rewrite 0 to 48 (example - 0900900900 => 48900900900),
3) for other calls, if CLI is 4 digits and starts with 100, set it to 48900900900.</P>

<DT><B>Example 4 (CLIR):</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[RewriteCLI]
in:192.168.1.0/24=any=hide
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>This example causes caller's number to be removed from Setup messages
originating from the 192.168.1.0/24 network. It also causes proper presentation
and screening indicators to be set in Setup messages.</P>
</DL>
</P>
<P>
<DL>
<DT><B>Format for an outbound rule:</B><DD>
<P><CODE>out:CALLER_IP=CALLEE_IP [pi=[allow|restrict][,forward|apply|applyforterminals]] [cli:|dno:|cno:]number_prefix(=|~=|*=)NEW_CLI[,NEW_CLI]...</CODE></P>
<P>The <CODE>out:</CODE> prefix tells that this is an outbound rule, the <CODE>CALLER_IP</CODE>
and the <CODE>CALLEE_IP</CODE> will be used to match the rule and can be a single IP
or a subnet address.<BR></P>
<P>The optional <CODE>pi=</CODE> parameter controls CLIR (Calling Line Identification Restriction)
features. Specifying either <CODE>allow</CODE> or <CODE>restrict</CODE> forces the presentation indicator
to be set to "presentation allowed" or "presentation restricted". <CODE>forward</CODE>, <CODE>apply</CODE>
and <CODE>applyforterminals</CODE> controls how the received (if any) presentation indicator
is processed by the gatekeeper. <CODE>forward</CODE> means just to forward it to the callee as-is,
<CODE>apply</CODE> means hiding CLI if the PI is set to "presentation restricted", <CODE>applyforterminals</CODE>
is similar to <CODE>apply</CODE>, except that the CLI is hidden only when sending the call to a terminal,
not a gateway.<BR></P>
<P>The prefix <CODE>cli:</CODE>, <CODE>dno:</CODE> (the default) or <CODE>cno:</CODE> selects what number
will be used to match the <CODE>number_prefix</CODE> - a caller id (CLI/ANI),
a dialed number or a destination/called number (the dialed number after rewrite).
Number matching/rewriting can be done in three ways:
<UL>
<LI><CODE>=</CODE> - a <CODE>cli</CODE> or <CODE>dno</CODE> number will be matched using a prefix
match against <CODE>number_prefix</CODE> and, if the match is found,
CLI will be replaced with NEW_CLI,</LI>
<LI><CODE>~=</CODE> - a <CODE>cli</CODE> or <CODE>dno</CODE> number will be matched using an identity
match against <CODE>number_prefix</CODE> and, if both numbers are the same,
CLI will be replaced with NEW_CLI,</LI>
<LI><CODE>*=</CODE> - (VALID ONLY FOR <CODE>cli</CODE>) a <CODE>cli</CODE> number will be matched using
a prefix match against <CODE>number_prefix</CODE> and, if the match is found,
the matched CLI prefix (<CODE>number_prefix</CODE>) will be replaced
with a NEW_CLI prefix.</LI>
</UL>

After the equality sign (=/&nbsp;=/*=), a list of new CLI values to be used is specified.
If more than one value is configured, one will be chosen on a random basis.
It's possible to specify entire number ranges, like 49173600000-49173699999.
There is a special string constant "any" which can be used in place
of the <CODE>CALLER_IP</CODE>, the <CODE>CALLEE_IP</CODE> or the <CODE>number_prefix</CODE>. 
To enable <CODE>CLIR</CODE> for this rule, use a special string constant <CODE>"hide"</CODE>
or <CODE>"hidefromterminals"</CODE> instead of the list of new CLI values.</P>

<DT><B>Example 1:</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[RewriteCLI]
out:any=192.168.1.1 any=1001
out:any=192.168.1.2 any=1002
out:any=any cno:123=1003
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>These rules set a fixed ANI/CLI for each terminating IP:
1) present myself with ANI 1001, when sending calls to IP 192.168.1.1,
2) present myself with ANI 1002, when sending calls to IP 192.168.1.2.
3) present myself with ANI 1003, when calling 123</P>

<DT><B>Example 2:</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[RewriteCLI]
out:any=192.168.1.1 any=1001-1999,3001-3999
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>This rule randomly selects ANI/CLI from range 1001-1999, 3001-3999
for calls sent to 192.168.1.1.</P>

<DT><B>Example 3 (CLIR):</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[RewriteCLI]
out:any=any any=hidefromterminals
out:192.168.1.1=any any=hide
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>In this example each subscriber has enabled CLIR, so all calls to terminals
will have a caller's number removed and presentation/screening indicators set.
Calls to gateways will have the presentation indicator set to "presentation restricted"
and the caller's number will not be removed to allow proper call routing and number
removal at the destination equipment.<BR>
One exception to these rules are calls from 192.168.1.1 which will have a caller's number
always removed, no matter whether calling a terminal or a gateway.</P>

<DT><B>Example 4 (CLIP):</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[RewriteCLI]
out:any=192.168.1.1 any=hide
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>In this example CLIP (Calling Line Identification Presentation) feature
is disabled for the user 192.168.1.1.</P>

<DT><B>Example 5 (CLIR):</B><DD>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[RewriteCLI]
out:192.168.1.1=any pi=restrict,apply cli:.*=.
out:any=any pi=allow cli:.*=.
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>These rules do not change CLI (.*=.) and:
1) enable CLIR for an endpoint 192.168.1.1. <CODE>apply</CODE> tells the gatekeeper
to not only set the PI, but also to hide the number.
2) force CLI presentation for other endpoints.</P>
</DL>
</P>

<P>The rule matching process has a strictly defined order:
<OL>
<LI>the closest caller's IP match is determined (closest means with the longest
network mask - single IPs have the highest priority, "any" has the lowest
priority),</LI>
<LI>(outbound rules) the closest callee's IP match is determined,</LI>
<LI>the longest matching prefix/number is searched for the given IP/IP pair
in the following order:
<OL>
<LI><CODE>dno:</CODE> type (dialed number) rules are searched,</LI>
<LI><CODE>cno:</CODE> type (destination/called number) rules are searched,</LI>
<LI><CODE>cli:</CODE> type (caller id) rules are searched.</LI>
</OL>
</LI>
</OL>

After a match for caller's/caller's IP is found, no more rules
are checked, even if no prefix/number is matched inside the set of rules
for these IPs.</P>

<P>On the Windows platform, there is a problem with duplicated config
keys in INI files, so GnuGk provides a workaround for this restriction. This example
will not work because of the same key (<CODE>in:192.168.1.1</CODE>):
<BLOCKQUOTE><CODE>
<PRE>
[RewriteCLI]
in:192.168.1.1=1001=2001
in:192.168.1.1=any=2000
</PRE>
</CODE></BLOCKQUOTE>

As a workaround, you can use a string with percent signs (%) at the beginning
and at the end before the key. This prefix will be automatically stripped
from the key name before loading rules:
<BLOCKQUOTE><CODE>
<PRE>
[RewriteCLI]
%r1% in:192.168.1.1=1001=2001
%r2% in:192.168.1.1=any=2000
</PRE>
</CODE></BLOCKQUOTE>
</P>

<H2><A NAME="clirewritesql"></A> <A NAME="ss6.18">6.18</A> <A HREF="manual.html#toc6.18">Section [RewriteCLI::SQL] </A>
</H2>

<P>Use the 
<A HREF="manual-4.html#database">common database configuration options</A>
to define your database connection for this module.</P>
<P>Please note that the switches (not the rules) from the 
<A HREF="#clirewrite">RewriteCLI</A> section,
like <CODE>ProcessSourceAddress=</CODE>, <CODE>RemoveH323Id=</CODE> and <CODE>CLIRPolicy=</CODE> also apply
to the rewrite rules from this section.</P>
<P>
<UL>
<LI><CODE>InboundQuery=SELECT ...</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>Define a rewriting query to run when the call comes in.</P>

</LI>
<LI><CODE>outboundQuery=SELECT ...</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>Define a rewriting query to run when the call is sent out. The called number parameter has already passed all rewriting steps.</P>
</LI>
</UL>
</P>
<P>The first field returned by the query is used as the new CLI.
If the query returns no rows, the CLI is left unchanged.
The queries can be parameterized - that means parameter
replacement is made before each query is executed. The following parameters are defined:
<UL>
<LI><CODE>%{cli}</CODE> - the original CLI or first sourceAddress if no CLI exists (on outbound queries, it can already be rewritten by an Inbound query)</LI>
<LI><CODE>%{callerip}</CODE> - the calling IP</LI>
<LI><CODE>%{called}</CODE> - the called number (the dialed number on inbound queries and the rewritten number in outbound queries)</LI>
</UL>
</P>
<P>In most cases you will probably only use the %{cli} parameter.</P>


<H2><A NAME="rewritesourceaddr"></A> <A NAME="ss6.19">6.19</A> <A HREF="manual.html#toc6.19">Section [RewriteSourceAddress] </A>
</H2>

<P>With the switches in this section you can filter the sourceAddress elements that are
transported in a Setup message. (Please note that the
<A HREF="#clirewrite">RewriteCLI</A> and 
<A HREF="#clirewritesql">RewriteCLI::SQL</A>
rules also influence the sourceAddress.)</P>
<P>
<UL>
<LI><CODE>OnlyE164=1</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>With this switch you can filter out all elements that are not of type E.164.</P>

</LI>
<LI><CODE>OnlyValid10Dand11D=1</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>With this switch you can filter out all elements that are not valid 10-digit or 11-digit US numbers.
They may be of any alias type (unless OnlyE164 is set), but no formatting characters are allowed.
11-digit numbers must start with 1 and area codes must start with 2..9.</P>

</LI>
<LI><CODE>MatchSourceTypeToDestination=1</CODE><BR>
Default: <CODE>0</CODE><BR>
<P>With this switch you can filter out all elements that do not match the destination Type (E.164 or URI)
If you call an E.164 number (Q931 IE: Called-Party-Number present) everything other then dialdigit source will be filtered.
If you call a URI (destination AliasAddress type) everything other then URI source will be filtered.
This switch has no effect on any other destination type. For example H323ID or TransportID AliasTypes.</P>

</LI>
<LI><CODE>ForceAliasType=1</CODE><BR>
Default: <CODE>-1</CODE><BR>
<P>values  0-dialedDigits 1-h323_ID 2-URI-ID
With this switch you can force the source and destination AliasAddress to the supplied type. 
Used in conjunction with MatchSourceTypeToDestination to change the AliasType. 
for instance change url_ID to h323_ID so the remote gateway can process the message.</P>

</LI>
<LI><CODE>ReplaceChar=+,0;#,*</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>With this switch you can remove/replace characters on the callers source address such as +.</P>

</LI>
<LI><CODE>Rules=01,18001234567</CODE><BR>
Default: <CODE>N/A</CODE><BR>
<P>With this switch you can replace the CallSourceAddress if there is a prefix match.
You can use this to assign a common valid E.164 number to non-E.164 numbers for the purpose of callerID.</P>

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

<HR>
<A HREF="manual-7.html">Next</A>
<A HREF="manual-5.html">Previous</A>
<A HREF="manual.html#toc6">Contents</A>
</BODY>
</HTML>
gnugk 2:3.4-2-1 / usr / share / doc / gnugk / manual / manual-6.html
