Hi Andrew,
GnuGk can't generate a Setup (or ARQ) to it's parent for an LRQ. The
LRQ isn't the start of a call, its just a request for address
resolution. Thats why GnuGk has to send an LRQ to it's parent to
forward this address resolution.
The LRQ it generates is indeed rather bare-bone and could be extended,
but it seems to by valid. The hop count is an optional field.
Regards,
Jan
Andrew Herdman wrote:
> Thanks Jan, I'll send a PM about those policy pieces that aren't supported
> later.
>
> While trying to make this all work, I switched topologies yesterday, and
> made my edge gatekeeper a child to my inside gatekeeper, and am using SQL
> policies to keep internal domains coming inbound properly, and route
> external URI out the edge device. It mostly works, 90% of the way there.
>
> I have one absolutely weird situation thou. In the testing, there is a VCS
> sending me an LRQ for an endpoint on my internal domain, it is a proper LRQ
> with hop count and was derived from SRV DNS records. The GNU/GK then
> sends the LRQ to the parent, but the LRQ is not complete, it has no hop
> count on it for instance. Now I've never seen a child send an LRQ to a
> parent before, not that I've ever done this particular situation before, but
> as there is no where to really configure LRQ parameter's for a child, this
> strikes me as wrong, as I was expecting a Setup Message from the Child to
> the Parent.
>
> I could avoid this by putting in some SQL rules to match the domain and set
> the gateway IP to the internal GNU/GK, but that requires additional
> configuration for every domain, those in the operational world know that the
> less configuration changes you need to do, the better.
>
> Some relevant config;
>
> [RasSrv::LRQFeatures]
> NeighborTimeout=2
> SendRetries=2
> ForwardHopCount=5
> AcceptForwardedLRQ=0
> ForwardResponse=0
> ForwardLRQ=depends
> AcceptNonNeighborLRQ=1 <-- Needed to accept inbound LRQ's from 3rd parties.
> AcceptNonNeighborLCF=0
>
> [RoutingPolicy]
> default=sql,srv,dns,parent,explicit
>
> [RoutingPolicy::OnARQ]
> default=sql,srv,dns,parent,explicit
>
> [RoutingPolicy::OnLRQ]
> default=sql,parent,explicit
>
> [RoutingPolicy::OnSetup]
> default=sql,srv,dns,parent,explicit
>
> [Endpoint]
> Gatekeeper=Parent_IP
> Type=Gateway
> Vendor=GnuGK
> H323ID=ME
> Prefix=1234
> TimeToLive=60
> RRQRetryInterval=3
> ARQTimeout=2
> UnregisterOnReload=1
> Discovery=0
> UseAlternateGK=0
> GatekeeperIdentifier=Parent
> EndpointIdentifier=ME
> ForwardDestIp=1
> DisableH.460.23=1
>
> Thanks
> Andrew
>
> -----Original Message-----
> From: Jan Willamowius
> Sent: Wednesday, November 16, 2011 5:42 AM
> To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: Problem with DNS and SRV policies
>
> Hi,
>
> traditionally GnuGk only applies DNS related policies to calls that
> originated locally. The reasoning was that the sending gatekeeper could
> have done the DNS lookup and there is no point in trying the time
> consuming DNS lookup again at each gatekeeper.
>
> But I agree that there are cases where one wants to try the DNS lookup
> on incoming LRQs. The DNS policy has a switch to turn on lookups for
> LRQs
>
> [Routing::DNS]
> ResolveNonLocalLRQ=1
>
> The SRV, RDS or ENUM policy currently don't have such a switch.
>
> Regards,
> Jan
>
>
> Andrew Herdman wrote:
> > I’m building a GNU/GK at the edge of my network to handle outbound and
> > inbound URI dialling and have run into an issue which I cannot figure out.
> >
> > My internal gatekeepers LRQ the URI to my gateway gatekeeper, I have
> > Policies as follows;
> >
> > [RoutingPolicy]
> > default=sql,internal,neighbor,srv,dns,explicit
> >
> >
> > [RoutingPolicy::OnARQ]
> > default=sql,internal,neighbor,srv,dns,explicit
> >
> >
> > [RoutingPolicy::OnLRQ]
> > default=sql,internal,neighbor,srv,dns,explicit
> >
> >
> > [RoutingPolicy::OnSetup]
> > default=sql,internal,neighbor,srv,dns,explicit
> >
> > When I dial the URI, my gateway gatekeeper recieves the LRQ, goes through
> > the routing policy, finds the SRV records and then indicates that they are
> > “Skipped, using only local LS for LRQs”. And as well policy DNS says
> > “Policy DNS only supports LRQs that resolve locally”.
> >
> > Here’s the log;
> >
> > gksql.cxx(321) SqlPolicy Executing query: select * from
> > SQL_CALL_CONTROL('123456@xxxxxxxxx')
> > job.cxx(363) JOB Worker threads: 10 total - 10 busy, 0 idle
> > Routing.cxx(1624) SqlPolicy: query returned no rows
> > Routing.h(185) ROUTING Checking policy Internal for the request LRQ
> > 11
> > Routing.h(185) ROUTING Checking policy Neighbor for the request LRQ
> > 11
> > Routing.h(185) ROUTING Checking policy SRV for the request LRQ 11
> > pdns.cxx(503) DNS SRV Lookup party.com service _h323cs._tcp.
> > pdns.cxx(523) DNS SRV Record found _h323cs._tcp.party.com
> > Neighbor.cxx(1633) ROUTING SRV CS converted remote party 123456@xxxxxxxxx
> > to 123456@1.2.3.4:1720
> > Neighbor.cxx(1633) ROUTING SRV CS converted remote party 123456@xxxxxxxxx
> > to 123456@1.2.3.5:1720
> > Neighbor.cxx(1633) ROUTING SRV CS converted remote party 123456@xxxxxxxxx
> > to 123456@1.2.3.6:1720
> > pdns.cxx(503) DNS SRV Lookup party.com service _h323ls._udp.
> > pdns.cxx(523) DNS SRV Record found _h323ls._udp.party.com
> > Neighbor.cxx(1571) ROUTING SRV LS located domain party.com at
> > 1.2.3.4:1719
> > Neighbor.cxx(1594) ROUTING Skipped, using only local LS for LRQs
> > Neighbor.cxx(1571) ROUTING SRV LS located domain party.com at
> > 1.2.3.5:1719
> > Neighbor.cxx(1594) ROUTING Skipped, using only local LS for LRQs
> > Neighbor.cxx(1571) ROUTING SRV LS located domain party.com at
> > 1.2.3.6:1719
> > Neighbor.cxx(1594) ROUTING Skipped, using only local LS for LRQs
> > Routing.h(185) ROUTING Checking policy DNS for the request LRQ 11
> > Routing.cxx(649) ROUTING Policy DNS only supports LRQs that resolve
> > locally
> > Routing.h(185) ROUTING Checking policy Explicit for the request LRQ
> > 11
> > RasSrv.cxx(394) LRJ|10.10.10.10|123456@xxxxxxxxx:h323_ID
> > RasSrv.cxx(234) RAS Send to 10.10.10.10:1719
> >
> >
> > I am stumped, any help is appreciated.
> >
> > Thanks
> > Andrew
--
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. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________________
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/
