Please see the attached document (by Chih-Wei Huang).
It is not up-to-date, but I'm sure you'll be able to find there some answers.
--
Best regards,
Andrey S Pankov.
> Somebody can explain how Routin policy works in GnuGK 2.2 Beta 2?...
Hi all,
Here is the changes/features of GnuGK 2.2beta1.
Sorry for the late documents.
Most parts of the codes are rewritten to improve
efficiency, maintainability and code reusability.
It includes:
* object factory
* new thread model
* unified sockets handling mechanism
* RAS type traits
* multi-threaded RAS server
* thread-safed gkauth
Most of the changes are in the underlying architecture
that don't affect the user level.
I will write documents to describe more about them later.
Two major changes that affect and are useful to you
* configurable routing policies
The new routing architecture of GnuGK 2.2 is flexible and extensible that
allows you to rearrange routing policies for different situations at runtime.
A routing policy is a rule to determine the destination for a given routing
request. If a policy can't determine the fate of the request, it passed to the
next policy.
There are two kinds of policies, direct and indirect (or forwarded). A
direct policy determine the destination directly, while an indirect policy
rewrites the request and forwards it to the next policy.
Currently five routing policies are implemented
* explicit - the destination is explicitly specified in the routing
request
* internal - the classical rule, search the destination in
RegistrationTable
* parent - route a call to the parent gatekeeper by ARQ
* neighbor - route a call to neighbors by exchanging LRQs
* dns - the destination is resolved from DNS, provided it is resolvable
A routing request is issued when the gatekeeper has to make a routing
decision. There are four possible situations, namely, RAS ARQ and LRQ, Q.931
Setup and Facility (with reason callForwarded).
[RoutingPolicy]
h323_ID=dns,internal
002=neighbor,internal
Default=internal,neighbor,parent
It means, for aliases of type h323_ID, use dns policy first, then follows
the internal policy; for aliases begin with 002, use neighbor policy and then
the internal policy; otherwise, use internal, neighbor, parent policies
sequentially.
Moreover, you can specify policies for different routing requests, for
example,
[RoutingPolicy::OnLRQ]
09=neighbor
...
If you don't specified any RoutingPolicy section, the default policies are
explicit,internal,parent,neighbor, just like 2.0.
The new routing architecture solves many old problems
that can't(hardly) be implemented in 2.0. For example,
* route a call from a neighbor to the parent
* route a call from the parent to a neighbor
* forward a call to neighbor/parent
and more...
To provide a new routing policy, just include "Routing.h", derive from the
abstract class Policy, and override the four virtual functions OnRequest().
Then associate it with an identifier (a C-style string) by SimpleCreator so it
can be created by Factory<Policy>.
* new neighboring system
Now you can define profile of a neighbor GK like the following.
If multiple LCFs are received from different neighbors,
the one with most matched prefix and highest priority will be selected.
[RasSrv::Neighbors]
CitronProxy=10.0.1.1;09 # old style
TestGK=GnuGK # new style: id=type of neighbor
;CiscoGK=CiscoGK
[Neighbor::TestGK] # profile for TestGK
; IP:port or FQDN of this NB
Host=10.0.1.4
; gatekeeperIdentifier of this NB
GatekeeperIdentifier=gkid
; Prefixes to send to the NB, format: prefix:priority,prefix:priority,...
SendPrefixes=09,080:2
; accept these prefixes from this NB
AcceptPrefixes=09,08,07
Password=
; whether to resolve the domain name every time
Dynamic=1
; the hopCount set in LRQs sent to the NB
ForwardHopCount=2
; if the NB sends a forwarded LRQ, accept or not
AcceptForwardedLRQ=1
; whether to forward response for this NB
; if yes, the GK waits reply (LCF/LRJ) from forwarded NBs and send result
; to the requesting NB (the NB the original LRQ comes from)
ForwardResponse=1
; whether to forward LRQ for the NB (never, always, depend)
ForwardLRQ=never
Some minor changes:
* MySQL support is rewritten by MySQL C API directly
so you don't need mysql++ any more. (thanks to Hu Yuxin)
The section MySQLAuth is renamed to MySQLPasswordAuth for consistency.
The name of key field and queried field(s) are renamed
to the same for every section for simplicity.
For example,
[MySQLPasswordAuth]
Host=10.0.1.10
Database=billing
User=bruce
Password=testtest
Table=Account
; old name: IDField
KeyField=IPN
; old name: PasswordField
DataField=Password
ExtraCriterion=Kind < 2
* SimplePasswordAuth (and all its derivatives) now caches result returned
by GetPassword method, no matter the request is authenticated or not.
(in 2.0 only an authenticated password is cached)
* The option CallUnregisteredEndpoints is obsolete.
Use explicit routing policy rule instead.
TODO:
* Port virtual queue feature in 2.0 by new routing architecture.
* Radius support
* Accounting/call duration limit
* Grouping endpoints
* More routing policies
...
--
~ Chih-Wei Huang (cwhuang@linux.org.tw)
'v' CLDP Project : http://www.linux.org.tw/CLDP/ (Coordinator)
// \\ CLE Project : http://cle.linux.org.tw/CLE/ (Developer)
/( )\ I18N Project : http://i18n.linux.org.tw/ (Translator)
^`~'^ HomePage : http://www.cwhuang.idv.tw/
