Simon Horne wrote: > > > Response inline. > > ----- Original Message ----- > From: "Dimitris Daskopoulos" <dimitris@xxxxxxxxxxx > <mailto:dimitris@xxxxxxxxxxx>> > To: "GNU Gatekeeper Users" <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > <mailto:openh323gk-users@xxxxxxxxxxxxxxxxxxxxx>> > Sent: Saturday, November 04, 2006 5:13 AM > Subject: Re: ENUM Support for GNUGK > ... > > Does the SRV method always return the ras address? > > Is the signaling one returned in other cases? > > It depends on whether a signalling address SRV record exists. If one > does then it is used over the RAS address. There is a preference order. > So, depending on the kind of SRV returned, GnuGk decides whether to LRQ the returned address, or attempt CallSignaling on it? > > > > > preform LRQ for user > > > at gk.mysite.com:1719, LCF returns 210.93.x.x:1720 as the signalling > > > address of user. > > > > > ... if the user is locally registered, and if not, LCF may return the > > address of a gateway. Sounds like exactly what I asked for. > > > > > DNS > > > no SRV Record so resolve gk.mysite.com to 65.234.x.x > > > > > > ACF tells EP to call gateway directly at 210.93.x.x:1720 > > > > You mean 210.93.y.y:1720 as gateway (as opposed to 210.93.x.x:1720 which > > was the endpoint signaling address further up). > > No. Same function can be used for gateway or endpoint, I just have > incorrectly used the word gateway instead of endpoint. > > > > > > If no DNS SRV > > > record available then route to gatekeeper at 123.234.x.x:1720 > > > > > I don't understand this last sentence. > > Unless it was meant to replace the previous one and not to complement > > it. Both statements assume "no DNS SRV record". > > No the first one refers to endpoint registered locally at > 210.93.x.x:1720 and the second, using DNS (no SRV) to resolve the > gatekeeper address and route the signalling through the call signal > address of the gatekeeper at 123.234.x.x:1720. Sorry for the confusion > If the ENUM lookup returns user@xxxxxxxxxxxxx (65.234.x.x) and no SRV records exist, then DNS resolution will merely return user@xxxxxxxxxx so the a call will be attempted on the signaling address of 65.234.x.x. I don't see how 123.234.x.x:1720 comes into play, when no SRV records exist and no LRQs are exchanged with the gatekeeper. Or is it that the call to user@xxxxxxxxxx:1720 (GnuGk in proxy mode) will require resolution of target address "user" and trigger call to 123.234.x.x:1720 ? Sorry, I am confused about the role of this second gatekeeper (123.234.x.x). > > > > > So to fully answer you question > > > > > > [RoutingPolicy] > > > default=enum,srv,dns > > > (with the CVS version of GnuGk compiled with DNS support in pwlib) > > > > > Is there a reason for the DNS method to always follow the ENUM method? > > If the ENUM lookup always returns explicit addresses, > > e.g. 12345678@xxxxxxxxxx:1720 <mailto:12345678@xxxxxxxxxx:1720> > > do we need to append the DNS method? > > I tried to get this to work without dns, but with no success. > > I think you might of highlighted an issue in the routing. In theory no > it does not require DNS however as it is the form user@address it may > need to use the DNS routing policy to resolve. This might need to be > addressed. > I see. I have tried to use ENUM records with IP addresses returned and [RoutingPolicy] default=enum,explicit but with no success. It seems "dns" is always required after a ENUM lookup. > > > > Semantically, the DNS method is a little different than all the other > > routing methods. Once other methods are matched, address resolution > > stops. But the DNS method is applied even after a previously successful > > routing step. So it has to follow any other method that may return > > non-explicit addresses for the call to proceed. Correct? > > Yes. > > Additional note: There is a major security risk in using ENUM and LRQ's > (SRV records) to resolve an endpoint/gateway address, as the gatekeeper > may need to receive a LRQ from a gatekeeper which is not predefined as a > neighbor in the routing policy. You mean: EP -> [Gnugk-A] -> ENUM -> LRQ some non-neighbour [GnuGK-B] So GnuGk-A needs to be able to accept an LRQ from GnuGk-B, even though GnuGk-A may not be listed in GnuGk-B as a neighbour? Absolutely. If the admin of GnuGk-B has ENUM/SRV records pointing to it, he is probably aware that he may also receive LRQs from non-neighbours. > I have redressed that by extending the > neighbor policy to accept LRQ from non-neighbors (by default is switched > off) "switched off"? My understanding was that it was "hardwired" into the code, with no way to change it by "config" means. Excellent! This was a much needed feature in cases of open gatekeeper peerings (such as the academic Videnet-GDS routing scheme). We had requested this feature on the list and it seemed that there was no way to configure GnuGk to serve LRQs from non-neighbours. We ended up implementing a new gatekeeper class that avoids neighbour checks, which seems to work, but we should probably discuss how to submit this as a feature of future GnuGk versions (we would be glad to offer our "simplistic" solution, if useful to others). Unless your solution is already part of the CVS. I am > and extending the authentication module to cover authentication of > LRQ's. This function is still experimental. > Great! Would you be willing to share your code? > Simon > Cheers, Dimitris Daskopoulos GRNET/RTS ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
