Jan Willamowius wrote: > Robert Kulagowski wrote: >> Jan Willamowius wrote: >>> Hi Robert, >>> >>> endpoints and neighbors are 2 different kinds of beasts. >>> With your config you are creating both endpoints with aliases ny, lon, >>> phi, cfo _and_ neighbors named ny, lon, phi, cfo. >>> The priorities you assigned to your endpoints, don't have any meaning >>> for your neighbors which just happen to have the same names. >>> I would definitely try to avoid using the same names for endpoints and >>> gatekeepers. >>> >>> Neighbors currently don't have priorities (to avoid long timeouts). >>> The one who answers first, gets the call. >> Ah, ok. I thought that since Neighbor "PHI" has a more specific >> SendPrefix "1215" versus the more generic "1" for NY and CFO, that the >> algorithm used is longest match. > > Longest match is the rule for endpoints (gateways), because we know > that when they handle the prefix, they will handle the full number > range below it. Neighbors on the other hand are queried if they can > handle a certain destination; they don't have to be able to handle > all numbers below their SendPrefix. > >> This presents a conundrum then - I'm not sure how I can accomplish the >> goals of local gatekeepers that are neighbored with GnuGK and still >> allow tail end hop-off. Back to the drawing board. >> >> Can you possibly explain a little more how and when you would use a >> neighbor versus an endpoint that has a prefix associated with it? > > You don't always have a choice; some destinations will only accept > calls (traditional endpoints and gateways) and others will only > answer to LRQs. > > If your destination can handle both, there are lots of factors which to > choose. If you known by the prefix, that a certain destination can > handle the call, I would treat it as a gateway and avoid the overhead > or LRQ/LCF. That way you can also use priorities, longest prefix > matching, call failover etc. > > If you don't know which of many destinations can handle a call, treat > them as neighbors and send them LRQs. OK, I gave this a try; if I don't configure as neighbor and instead only use prefix, then if a device is registered as 12156789012 with the gatekeeper at 10.244.4.5, if I try to place a H.323 call to that device the call path ends up going like this: device in Chicago -> GnuGK -> 10.244.4.5-> (Telco) ->10.244.4.5 -> 12156789012 So, the H.323 call ends up with two H.320 legs, hairpinned through the telco, which is not what I was expecting! :( If I configure as neighbor, then the GnuGK sends a LRQ to 10.244.4.5 and the call stays as H.323 from endpoint to endpoint, which is optimal. ------------------------------------------------------------------------------ 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/
