Stewart, I have tried the NetworkInterfaces directive, and I had the same trouble. I could not figure out what directive to use in order to fast start and/or H.245 tunneling. Can you point me to the location of that information? Sean -----Original Message----- From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Stewart Nelson Sent: Tuesday, October 04, 2005 6:52 PM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: 2 gnu gatekeepers working as neighbors Hi Sean, A few things you may be able to try quickly: Does using fast start and/or H.245 tunneling help? You have no NetworkInterfaces directive, so the NAT traversal is being done by the external gk. Have you tried setting NetworkInterfaces? If so, does it fail in the same way? Without NetworkInterfaces, you can't have endpoints on public IPs work directly with the internal gk (I assume you don't need that), so perhaps you could try having the internal gk be a child and register with the external gk. If the endpoints registered to the external gk are a different type from those on the internal gk, move one to be sure that the problem is related to the neighbor connection. If none of the above helps, use Ethereal to see precisely what is going wrong. I suspect that either H.245 or RTP addresses are not being properly translated, or the firewall is not forwarding them properly. --Stewart ----- Original Message ----- From: "Sean Salomon" <ssalomon@xxxxxxxx> To: <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> Sent: Wednesday, October 05, 2005 2:01 AM Subject: RE: 2 gnu gatekeepers working as neighbors Stewart, I am running a similar configuration. I have one gatekeeper behind a firewall as a proxy. I have endpoints registering with that proxy(gnugk). I then have that internal proxy setup as a neighbor to a gatekeeper on a external ip. Endpoints are registered to that external gateway. I would like to have both endpoints communicate. I have yet to get it working. I am able to call out. But when I call in and accept the call it gets dropped. It looks like the external gatekeeper is handing off the call as it should to the internal gatekeeper, but then the call is being dropped. Below is my internal gatekeeper config. Any help or hints would be appreaciated. [Gatekeeper::Main] Fourtytwo=42 Name=Icoegk SignalCallId=1 SupportNATedEndpoints=1 [GkStatus::Auth] rule=allow [RasSrv::LRQFeatures] CiscoGKCompatible=1 AcceptForwardedLRQ=1 ForwardHopCount=2 ForwardLRQ=always [RoutedMode] GKRouted=1 H245Routed=1 RemoveH245AddressOnTunneling=1 CallSignalHandlerNumber=2 AcceptNeighborsCalls=1 AcceptUnregisteredCalls=1 Q931PortRange=20000-20999 H245PortRange=30000-30999 [Proxy] Enable=1 InternalNetwork=xx.xx.0.0/16 ProxyForNat=1 ProxyForSameNat=1 T120PortRange=40000-40999 RTPPortRange=50000-59999 [RoutingPolicy] default=internal,neighbor [RasSrv::Neighbors] GK1=xxx.xxx.84.166;* Sean -----Original Message----- From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Stewart Nelson Sent: Tuesday, October 04, 2005 3:39 PM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: 2 gnu gatekeepers working as neighbors Hi Luca, When you said "Both gatekeepers have a public ip address" I assumed that each gatekeeper has two NICs, one of which is a public IP. Or, at least, the public IP is an address listed by ipconfig. But from your .ini file, it seems that the gk's are behind NATs. Is that correct? If so, I don't know if what you are trying to do with LRQ/LCF is supported -- I have not tried this myself, nor have I seen any posts from others having succeeded. When you get the 10049 error, is the address printed that for gk1? If so, it is probably trying to bind to that address, which may be a bug in the code. Perhaps Michal can comment on this. If it's the address for gk2, you might try adding some debugging statements, so we know why the system call is being rejected. Running a gk on a dynamic IP is not a big problem, if your IP changes only once or twice a year as a result of a network outage. But if your provider purposely changes your address (some do it every day) you will have trouble. Not only will all calls be dropped when the address changes, but you won't be able to call back right away, because it will take a while for dynamic DNS to propagate, and clients to realize the address to which they must register (or send LRQ). Regards, Stewart ----- Original Message ----- From: "-Luca-" <noceluca@xxxxxxxxxxx> To: <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> Sent: Tuesday, October 04, 2005 10:38 PM Subject: Re: 2 gnu gatekeepers working as neighbors Hi stewart, I've observed LRQ and LCF messages, and they are correct, the telephony service and the firewall are unable. I see that LCF is correctly read from gk1. I also keep a check of my gatekeeper.ini file :-) The ip 62.101.106.41 that you've tried connect to, is an ip that my provider dynamically assign to me. "I assume that the :0 means that gk1 was trying to connect to port 0, which was rejected by the OS" Well, i have tried to run the 2 getekeepers and the 2 clients in the same local lan, in this case all worked fine.(audio and video too) But i've see that when the gk1 open tcp to the gk2, the log show: Connect to 192.168.1.82:1721 from 192.168.1.81:0 Where gk1=192.168.1.81 gk2=192.168.1.82 I read in the manual this words: "Note to make proxy work, the gatekeeper must have direct connection to both networks of the caller and callee." So,I want to ask you, do you knows if is possible my configuration? PS: i made my test only with the 2.2.3 version of gnugk, tomorrow i'm trying with 2.0.9 version. I'm attaching my two gatekeeper.ini files. Thank you,stewart. ----- Original Message ----- From: "Stewart Nelson" <sn@xxxxxxxxxxx> To: <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> Sent: Monday, October 03, 2005 3:48 AM Subject: Re: 2 gnu gatekeepers working as neighbors > Hi, > > I assume that the :0 means that gk1 was trying to connect to > port 0, which was rejected by the OS. Use ethereal or the > trace to see if the correct call signal address and port > (that of gk2) is in the LCF. That should at least tell > you which end the trouble is at. > > Make sure that Telephony service is not running, and that > Windows firewall or other software firewall is not > butchering the packets. > > You should also check that gk2 is actually listening > on its public IP; I couldn't connect to 62.101.106.41 > port 1720 or port 1721. Of course, that may be because > of a firewall, it's on a non-standard port, > or gk2 wasn't running when I wrote this. > > --Stewart > > ----- Original Message ----- > From: "-Luca-" <noceluca@xxxxxxxxxxx> > To: <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> > Sent: Saturday, October 01, 2005 2:59 AM > Subject: 2 gnu gatekeepers working as neighbors > > > Hi all, > > I'm trying to make calls from 2 client registered at two different gnugks. > > --------------------------------- --------------------------------- > | Lan 1 | | Lan 2 | > | | | | > | | > | (client1) ------> (gk1) <------> gk2 <----- (clientt2) | > | | > | | | | > | | | | > --------------------------------- --------------------------------- > > Both gatekeepers have a public ip address and work in full proxy mode(h225 routed + proxy enable). > Both clients have private ip address. > When client1 try calling client 2, gk1 sends a LRQ message to gk2, and gk2 reply with LCF. > Then gk1 must forward setup message (sent from client1) to gk2... therefore gk1 try to open a tcp > connection to gk2, > at this point the gk1 log show this error: > > could not open/connect socket at 62.101.106.41:0 - WIN32 error 10049 > > > Does anyone knows what it's means?... or anyone that has already did a similar configuration? > > > Thanks a lot. > > -Luca- ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________________ 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/ ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id.49 Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/ ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________________ 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/ ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id?49 Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
