Hi Jeremy, you can avoid that particular error message by setting [RoutedMode] SupportNATedEndpoints=1 Regards, Jan Jeremy Wu wrote: > Hi Michal, > > I was able to gather a level 5 trace of the neighbor gatekeeper failed call. It looks like the issue is with the error that I get "Q931s Unregistered party is NATed. Not supported by policy. > > > 2009/01/15 15:22:14.185 4 ProxyChannel.cxx(1627) Q931s GWRewrite source for 72.233.250.179:1220: neighbor or explicit IP > 2009/01/15 15:22:14.185 3 gkauth.cxx(1067) GKAUTH default Setup check ok > 2009/01/15 15:22:14.185 5 Routing.cxx(201) ROUTING Checking policy Explicit for request Setup CRV=22781 > 2009/01/15 15:22:14.185 5 Routing.cxx(201) ROUTING Checking policy Internal for request Setup CRV=22781 > 2009/01/15 15:22:14.185 4 RasTbl.cxx(1416) Alias match for EP 69.91.223.144:1720 > 2009/01/15 15:22:14.185 5 Routing.cxx(207) ROUTING Policy Internal applied to the request Setup CRV=22781 > 2009/01/15 15:22:14.185 4 ProxyChannel.cxx(1948) Q931s Unregistered party is NATed. Not supported by policy. > 2009/01/15 15:22:14.185 2 RasTbl.cxx(2656) CallTable::Insert(CALL) Call No. 458, total sessions : 13 > 2009/01/15 15:22:14.185 2 gkacct.cxx(1028) GKACCT Successfully logged event 1 for call no. 458 > 2009/01/15 15:22:14.185 2 RasTbl.cxx(3063) CDR ignore not connected call > 2009/01/15 15:22:14.185 5 gkacct.cxx(806) GKACCT FileAcct - CDR string for event 2, call no. 458: CDR|458|02 2c 82 c5 4d 82 f7 15 3f 40 58 b1 96 17 04 ed|0|unconnected|Thu, 15 Jan 2009 15:22:14 -0800|72.233.250.179:1220| |69.91.223.144:1720|5068_gk2|0554444:dialedDigits|DougSR:h323_ID=2981232:dialedDigits|wa-k20-gk2; > 2009/01/15 15:22:14.185 3 gkacct.cxx(988) GKACCT FileAcct logged event 2 for call no. 458 > 2009/01/15 15:22:14.185 2 gkacct.cxx(1028) GKACCT Successfully logged event 2 for call no. 458 > 2009/01/15 15:22:14.186 4 ProxyChannel.cxx(842) Q931 Send to 72.233.250.179:1220 > > > I have the following settings on my GK: > > ;############################################################################ > ;# K20 Gatekeeper 2 configuration > ;############################################################################ > [Gatekeeper::Main] > Fourtytwo=42 > Name=wa-k20-gk2 > TimeToLive=60 > ;Home=216.186.94.5 > StatusPort=7000 > EndpointIDSuffix=_gk2 > > [RoutedMode] > GKRouted=1 > H245Routed=0 > CallSignalPort=1720 > AcceptUnregisteredCalls=1 > > AcceptNeighborsCalls=1 > RemoveH245AddressOnTunneling=1 > DropCallsByReleaseComplete=1 > SendReleaseCompleteOnDRQ=1 > > [RasSrv::LRQFeatures] > AcceptForwardedLRQ=1 > > > [RasSrv::Neighbors] > CWU=GnuGK > SeaGK=GnuGK > > [Neighbor::CWU] > GatekeeperIdentifier=CWU > Host=72.233.250.179 > SendPrefixes=298,0011479298 > AcceptPrefixes=* > > [RasSrv::LRQFeatures] > AlwaysForwardLRQ=1 > IncludeDestinationInfoInLCF=1 > CiscoGKCompatible=1 > ForwardHopCount=10 > > [RasSrv::RRQFeatures] > AliasTypeFilter=gateway;h323id > > [RasSrv::ARQFeatures] > ;Allows dialing the IP of an unregisterd endpoint > CallUnregisteredEndpoints=1 > RoundRobinGateways=1 > > [Gatekeeper::Auth] > ;use the PrefixAuth rules below to authorize all ARQs and LRQs. > PrefixAuth=required;ARQ,LRQ > default=allow > > > [PrefixAuth] > ALL=allow ipv4:ALL > > Any ideas on what parameters I'm missing that would lead it to reject the call based on the unregistered party being NAT'ed? > > Thanks, > -Jeremy > > > Jeremy Wu > Network Engineer, Customer Services > UW Technology Services > University of Washington > Box 355675 > Seattle, WA 98105-5675 > (Tel) 206-543-1981 (Fax) 206-685-7755 > > > > > > -----Original Message----- > From: Jeremy Wu > Sent: Friday, January 09, 2009 10:18 AM > To: 'openh323gk-users@xxxxxxxxxxxxxxxxxxxxx' > Subject: No Longer Accepting Calls from Neighbor GK on 2.2.7 > > So I tried using the following syntax: > > [RasSrv::LRQFeatures] > AcceptForwardedLRQ=1 > > [RasSrv::Neighbors] > CWU=GnuGK > > [Neighbor::CWU] > GatekeeperIdentifier=CWU > Host=72.233.250.179 > SendPrefixes=298,0011479298 > AcceptPrefixes=* > > And a call from the CWU gatekeeper (GK_C) to mine is still following the pattern where the setup message is received from GK_C, and my gatekeeper (GK_B) is sending back a ReleaseComplete. > > Any other ideas? > > Thanks, > -Jeremy > > -----Original Message----- > From: Jeremy Wu > Sent: Friday, January 09, 2009 8:58 AM > To: 'openh323gk-users@xxxxxxxxxxxxxxxxxxxxx' > Subject: RE: Openh323gk-users Digest, Vol 32, Issue 4 > > Thanks Michal, I was looking at that. My one question was in the [RasSrv::Neighbors] section, there are only 4 options for types of gatekeeper (GnuGK, CiscoGK, ClarentGK, GlonetGK). Do I just use GnuGK to identify Polycom neighbor gatekeepers as shown in your example? > > Thanks, > -Jeremy > ------------------------------ > > Message: 5 > Date: Fri, 9 Jan 2009 08:59:23 +0100 > From: "Zygmuntowicz Michal" <m.zygmuntowicz@xxxxxxx> > Subject: Re: No Longer Accepting Calls from > Neighbor GK on2.2.7 > To: "GNU Gatekeeper Users" <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> > Message-ID: <F99113EBC934431BB9BF014E0C33DD2E@treasure> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > Please check the new syntax for neighbor configuration - it should look like: > > [RasSrv::Neighbors] > GK_C=GnuGk > > [Neighbor::GK_C] > Host=72.233.250.179 > AcceptPrefixes=298,0011479298 > ... > > ----- Original Message ----- > From: "Jeremy Wu" <doctorwu@xxxxxxxxxxxxxxxx> > To: <Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> > Sent: Friday, January 09, 2009 2:09 AM > Subject: No Longer Accepting Calls from Neighbor GK on2.2.7 > > > > I'm wondering if someone can help me figure out what I'm missing. I've been running an GnuGK on 2.2.2 for many years, and have > > recently implemented a secondary GnuGK on 2.2.7. > > > > I've used pretty much the same config file for both GK. However, I am currently unable to receive calls from neighbored GKs on > > the gatekeeper running 2.2.7. So if my GK_A is my 2.2.2 gatekeeper, and GK_B is my 2.2.7 gatekeeper, I have a colleague running a > > GK_C that is a Polycom Path Navigator. GK_C is neighbored to both GK_A and GK_B with different prefixes. > > > > Using Wireshark I can see that calls from GK_C to GK_A process fine. But on calls from GK_C to GK_B, the 2.2.7 gatekeeper replies > > to his Setup message with a ReleaseComplete. I can make calls between endpoints registered on GK_B fine, and I can actually call > > from an endpoint on GK_B to GK_C successfully. I can also make calls between GK_A and GK_B successfully. > > > > I believe that I have the basic peering configurations set appropriately. > > > > [RoutedMode] > > AcceptNeighborsCalls=1 > > > > [RasSrv::Neighbors] > > GK_C=72.233.250.179;298,0011479298 > > > > And the fact that this same configuration works on my GnuGK running 2.2.2 confuses me. Am I missing a new parameter that was > > introduced in later revs? > > > > Thanks, > > -Jeremy -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________________ 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/
