The tricky part here is that the proxy should send an ARQ to the actual alternate gatekeeper which sent the call. I'll take a look to see what can be done.
----- Original Message ----- From: "ivan mitev" <ivan.mitev@xxxxxxxxx>
Sent: Saturday, January 22, 2005 1:55 PM
i'm experiencing a problem with the setup described below : when calling from terminal1 to a gateway behind gk_proxy, calls routed by the alternate gateway gk_2 are rejected by gk_proxy, while calls routed by gk_1 are not.
|------ gk_1 -----| gk_proxy -| |- terminal1 |------ gk_2 -----|
both gk_proxy and terminal1 register as endpoints with gk_1 ; terminal1 has gk_2 configured as alternate gk.
gk_1 and gk_2 are configured as alternate gks (with AlternateGK, SendTo, and SkipForwards), with GKRouted=1 H245Routed=1 ; this setup works nicely: both terminal1 and gk_proxy automatically "switch" to gk_2 when gk_1 is down. (there are a few issues with the alternate gk setup, but it's off topic here; if someone wants more info i'd be happy to share my experience).
the problem arises when terminal1 uses gk_2 (eg. because gk_1 is unreachable), but when gk_proxy still uses gk_1. in that case, calls proxied via gk_2 to any gateway/terminal behind gk_proxy are rejected; from the log on gk_proxy:
[...]
RasSrv.cxx(1238) RAS Trapped RCF
ProxyChannel.cxx(711) Q931s Received: Setup CRV=26846 from [GK_2_IP]:46889
ProxyChannel.cxx(1505) Q931 Reject unregistered call [mac mac]
RasTbl.cxx(1969) CallTable::Insert(CALL) Call No. 27, total sessions : 1
gkacct.cxx(959) GKACCT Successfully log ged event 1 for call no. 27
RasTbl.cxx(2140) CDR ignore not connected call
gkacct.cxx(919) GKACCT FileAcct logged event 2 for call no. 27
gkacct.cxx(959) GKACCT Successfully logged event 2 for call no. 27
yasocket.cxx(528) Q931s Delete socket [GK_2_IP]:46889
RasTbl.cxx(1393) Gk Delete Call No. 27
[...]
the correct behavior should be that gk_proxy accepts calls from the alternate gateway(s) returned by gk_1. (btw, an "alternate_gk" option in the endpoint section would be welcome to avoid the case when gk_1 is unreachable and gk_proxy starts/restarts and doesn't have any knowledge of alternate gk).
any clue on how to fix that without allowing all calls on gk_proxy ?
gnugks in this setup are statically compiled on a FC2 system with "pandora" releases of pwlib/openh323.
thanks ! ivan
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________________
List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
