If you do sql based routing, you can replicate the routing database to a number of servers. Or you can use the forwarding feature to distribute local registrations, but that quickly gets tricky to keep in sync, so I would stick to replicating the sql database. Regards, Jan Hossein Aminaiee wrote: > Hi, > > > Thanks again Jan. I want to know whether GnuGK as a border element > provides replicating its own routing database to the other gatekeepers > in it's administrative domain or not. Roughly speaking, in the case of > border element failure, we want each gatekeeper in the zone to have > routing table similar to that of border element before it's failure. > Therefore, each gatekeeper would have the complete routing table itself, > enabled to continue operation while the border element is down. > > > Best, > > Hossein > > > > > Jan Willamowius wrote: > > > Hi Hossein, > > > > you can configure whether to forward or not. Take a look at the > > Neighbor section in the manual: > > http://www.gnugk.org/gnugk-manual-10.html > > > > Caching all results of LRQs takes a more advanced config, but I've > > already done that with GnuGk for clients whose lookups were very > > expensive. You have to intercept the lookup results and store them in a > > database and then use the 'sql' policy to retrieve them again (at least > > thats one way to do it). > > > > Regards, > > Jan > > > > > > Hossein Aminaiee wrote: > > > >> Dear Simon, > >> > >> > >> Thank you for your answer. To make myself sure, will the GnuGK as a > >> border element have a caching mechanism inside, building a routing > >> table? In other words, having a GnuGK as a border element, does the LRQ > >> messages are resolved by the border element without going outside the > >> domain? > >> > >> > >> Hossein > >> > >> > >> Simon Horne wrote: > >> > >> > >>> Hossein > >>> > >>> GnuGk certainly can operate as a border element. You only need to have an 2 > >>> network interfaces one on the inside and one on the outside. There are no > >>> special configuration required, the gatekeeper will detect the 2 interfaces > >>> and should automatically accept registrations and route signalling and media > >>> between the two networks. > >>> > >>> Simon > >>> > >>> -----Original Message----- > >>> From: Hossein Aminaiee [mailto:hossein@xxxxxxxxxxx] > >>> Sent: Sunday, 13 December 2009 6:35 PM > >>> To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > >>> Subject: GnuGK and Peer Element support > >>> > >>> Hi > >>> > >>> > >>> Does anyone help me know whether the GnuGK supports the peer element (border > >>> element) concept or not. In other words, would it be possible to have a > >>> border element in a platform consisting the H323plus library and GnuGK? And > >>> if so, is there any documentation or hints about this matter? > >>> > >>> > >>> Any help would be appreciated. > >>> > >>> > >>> Best, > >>> > >>> Hossein Aminaiee > >>> > > > > -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
