Yuriy, your dump looks like your GnuGk is in direct mode. I know that GnuGk generally works fine in routed mode, even when H.460.18 is enabled. Please check a level 5 GnuGk trace to see if your gatekeeper really is in routed mode. If it is, you must have hit a very special error condition and to diagnose that, we'll also need a level 5 trace.
Regards, Jan Georgiewskiy Yuriy wrote: > > Hi, i think i found a bug in h46018 part of gnugk, call scheme: > > freeswitch-h323->GK-h323->cisco, freeswitch uses mod_h323 based on h323plus > library, > h46018 and h46023 enabled on both gnugk and freeswitch sides. Which happend: > > freeswitch send admission requets to gnugk > gnugk reply to freeswitch with admissionconfirm with destcallsignaladdress of > cisco, > after this all signaling between freeswitch and cisco goes directly, on > gnugk > we have a call in alerting/progrees waiting state until timeout occurces. > > We have GKRouted=1 and H245Routed=1, i think with this settings signaling > should > goes thorouch gk and gk need send it's own ip in admissionconfirm. we try > ProxyAlways=1 and Enable=1 in [Proxy] section with no luck, after this we > recompile > gnugk without h46018/h46023 and calls goes fine after this. i attach dump of > traffic > for this call, therhe is 91.193.236.4 is freeswitch, 91.195.204.1 GK and > 192.168.168.168 > is cisco. -- Jan Willamowius, [email protected], http://www.gnugk.org/ ------------------------------------------------------------------------------ _______________________________________________________ Posting: mailto:[email protected] 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/
