Andras Kovacs wrote: > Thanks. This will help. Would make sense to include 1-2 sentences on > this in GnuGK manual. I agree that we are missing the tutorial part of the manual. What we currently have is rather a reference manual about all the config options and thats already over 100 pages. If anybody would write up a tutorial on any related subject I'll gladly include it. ;-) > So, in best case, my top level GK will receive two LCF messages from > downstream partners. One can be ignored, etc. Both contains the same IP. > This sounds good. It shouldn't even receive 2 LCFs in most cases. The alternates are either/or. Only one should have the registration and the other should notice that it lost it (eg. using the TimeToLive on the registrations). There should only be a small time window when both gatekeepers think they have the registration. > How about routed mode? I did not mention we employ routed signaling > here. Where the flow of signal will go through when a call drops in from > an external network to my top level gatekeeper? Will this also forward > Q.931 down to both GKs? First SETUP message reaching the endpoint will > win the race? This should work in all modes: direct, routed or proxied. The upstream will pick one alternate that sends an LCF and use the signalling information provided in the LCF. It won't fork the call into 2 paths if it gets 2 LCFs. Regards, Jan > On 2011.09.28. 16:23, Jan Willamowius wrote: > > Hi Andras, > > > > there can be multiple neighbors serving the same prefix. > > If you upstream gatekeeper is neighbored to both alternates (with the > > same SendPrefix, in GnuGk terms), it will send an LRQ to both of them > > asking who is able to route the call. The alternate who currently has > > the endpoint registration is going to respond LCF and will get the call. > > > > There won't be ARQs between neighbors. > > > > Regards, > > Jan > > > > -- > Andras Kovacs > ------------------------------------------------------------- > NIIF/HUNGARNET e-mail: akov@xxxxxxx > Victor Hugo str. 18-22. tel: +36 1 450 3082 > H-1132 Budapest, Hungary fax: +36 1 350 6750 > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________________ > > 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/ > -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________________ 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/
