Thats what ForwardOnFacility is for. By default its off, but when you turn it on its supposed to handle this situation. [RoutedMode] ForwardOnFacility=1 Regards, Jan Simon Horne wrote: > Tobias > > I have seen this too. > The problem is that once an endpoint is registered you cannot call directly > and the call must go through the gatekeeper. When you call the endpoint you > receive back a facility message with routeCalltoGatekeeper which instructs > the caller to drop this call and call the gatekeeper. In the facility > message contains the gatekeeper address is the alternateAddress field. I > think there also should be an alternateAlias field so the call to the > gatekeeper knows where to forward on the call. I think this might be a bug. > We just need to find the time to debug the issue. > > Simon > > > > -----Original Message----- > From: Tobias Marquart [mailto:tobimarq@xxxxxx] > Sent: Wednesday, January 26, 2011 8:30 AM > To: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Subject: call setup through parent GK in proxy mode > > Hi all, > > we have a strange call setup behavior in a special situation. I hope that it > has to do with the gnugk config so that we can somehow fix it. > > We use gnugk in proxy mode (without any problems). Our gk is connected to a > gatekeeper hierarchy (one neighbor/parent gk). > > Consider 2 different types of external endpoints I try to call from a local > endpoint: > > 1) Endpoints that are not in any way connected to our Gatekeeper hierarchy, > I call them by IP-Address > 2) Endpoints that are connected to (=known in) our Gatekeeper hierarchy, but > not registered directly with our GK. > > The first type of endpoint works perfectly. > The second type works perfectly when dialing via h323alias/E.164 However > when trying to call these endpoints by using the IP-Address, the problem > starts: > First we realized an "unreachable destination" error at the local endpoint. > This is in a somehow "closed" and NATted network environment. > (when not behind NAT/firewall restrictions, the situation I describe below > is the same, but the call setup nevertheless works). > > We realized that the local endpoint tries to connect to the parent > gatekeeper directly (at a very late point in time of the call setup). > > Further analysis: > The local endpoint gets a "h.225 CS facility" packet from our gnugk at an > early point in the call setup. > In this packet there is mentioned the IP-Address of the parent GK as > "alternativeAddress". > This facility packet does not appear in any of the other call setup > scenarios (in the working scenarios there occurs an "Alerting" packet > instead). > The admissionRequest/admissionConfirm log entries on gnugk have absolutely > identical flags and options regardless of the call setup scenario. > > Gnugk just seems not not be able to do a "normal" call setup in that special > case. The problem occurs with several remote endpoints, so it seems to be a > general issue. > I have detailed gnugk-logs and wireshark packet traces (from the local > endpoint) available (via PM) in case this is necessary. However I hope that > this behavior is somehow known (and can be fixed easily). > > Btw: The situation happens also with the very newest gnugk release. > > I very much hope you can help me somehow, tia, Tobias -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________________ 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/
