<!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: 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>
<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 the various possible routing
policies within the gatekeeper work.</P>
<P>The incoming call requests can be routed using a number
of routing providers:</P>
<P>
<UL>
<LI><CODE>explicit</CODE><BR>
<P>The destination is explicitly specified in the routing
request.</P>
</LI>
<LI><CODE>internal</CODE><BR>
<P>The classical rule; search the destination in
RegistrationTable</P>
</LI>
<LI><CODE>parent</CODE><BR>
<P>Route the call using information sent by the parent GK in
reply to an ARQ the gatekeeper will send.</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 from DNS, provided it is
resolvable</P>
</LI>
<LI><CODE>vqueue</CODE><BR>
<P>Use the virtual queue mechanism and generate a RouteRequest
event to let an external application do the routing
(can only be used OnARQ or OnLRQ)</P>
</LI>
<LI><CODE>numberanalysis</CODE><BR>
<P>Provides support for overlapped digit sending for ARQ messages.
It 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 lookup to convert
real IDD E164 numbers into H323 dialing information. The servers
it looks up by default are <CODE>e164.voxgratia.net</CODE>, <CODE>e164.org</CODE> and <CODE>e164.arpa</CODE>.
To specify your own server you have to specify an environmental
variable PWLIB_ENUM_PATH with the address of your preferred
enum servers separated by a colon(:) on Linus and a semicolon (;) on windows. (PWLIB_ENUM_PATH is supported starting with PWLib 1.8.0; 1.7.5.2 (Pandora) doesn't support it.)</P>
<P>The enum policy replaces the destination with the information returned by ENUM server, so you must have the appropriate routing policies to finally route the call after the enum policy. Usually you should also have the dns policy after the enum policy, since the new location is often returned in the form of 'number@gatekeeper' and the dns policy is 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>
</LI>
<LI><CODE>srv</CODE><BR>
<P>DNS SRV or H.323 Annex Q. allows for the routing of calls using the H.323 URI.
Addresses can be set as user (at) domain. The H.323 signalling addresses are
stored in the DNS domain records. Addresses can be the signalling address or
LRQ address. </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 kind of 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 one of the messages is received which calls for 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, first the neighbors
are checked and 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 that fails the
parent.</P>
<P>For the ARQ, LRQ, Setup and Facility messages one would use the
[RoutingPolicy::OnARQ], [RoutingPolicy::OnLRQ],
[RoutingPolicy::OnSetup] and [RoutingPolicy::OnFacility] sections
using the 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,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 is beginning 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. 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>gw-alias=in|out=[!]original-prefix=target-prefix[;in|out...]</CODE></P>
<P>If the call matches the gateway, 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.
Multiple rules for the same gateway should be separated by ';'.</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>
</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=CitronGK
/ \
/ \
/ \
/ \
[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 GK 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 later will take effect first.</P>
<H2><A NAME="numberanalysis"></A> <A NAME="ss6.6">6.6</A> <A HREF="manual.html#toc6.6">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 - 10 digits and to all other at least 6 and at most 20 digits.</P>
</DL>
</P>
<H2><A NAME="clirewrite"></A> <A NAME="ss6.7">6.7</A> <A HREF="manual.html#toc6.7">Section [RewriteCLI]</A>
</H2>
<P>This section contains a set of rewrite rules for ANI/CLI numbers (caller id).
The rewrite process is done at two stages - inbound rewrite and outbound rewrite.
The inbound rewrite is done before any other Q.931 Setup message processing
(like inbound GWRewrite, authentication, accounting, ...) and it will have
visible effect inside auth/acct modules, as it affects Calling-Station-Id.
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>ProcessSourceInfo=1</CODE><BR>
Default: <CODE>1</CODE><BR>
<P>In addition to rewriting a Calling-Party-Number IE also a sourceInfo
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>Here a global presentation indicator 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 send 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 tells 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 a whole subnet).<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 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 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 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, there follows a list of new CLI values to be used.
If more than one value is specified, a 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", that can 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 a 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 tell 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:any=any=0
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>These rules tell 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 other calls, set CLI to 0.</P>
<DT><B>Example 3:</B><DD><P>
<BLOCKQUOTE><CODE>
<PRE>
[RewriteCLI]
%r1% in:192.168.1.0/24=0048*=48
%r2% in:192.168.1.0/24=0*=48
in:any=100.~=48900900900
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>These rules tell 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 whole network 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 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 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 (=/ =/*=), a list of new CLI values to be used follows.
If more than one value is specified, a one will be chosen on a random basis.
It's possible to specify whole number ranges, like 49173600000-49173699999.
There is a special string constant "any", that 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
</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.</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 only a 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 actually,
2) force CLI presentation for other endpoints.</P>
</DL>
</P>
<P>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 Windows platform, there is a problem with duplicated config
keys, so there is 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 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>
<HR>
<A HREF="manual-7.html">Next</A>
<A HREF="manual-5.html">Previous</A>
<A HREF="manual.html#toc6">Contents</A>
</BODY>
</HTML>
