The sjphone NAT/FIREWALL shows blocked Hi all, I will be glad to receive your help. I have my gatekeeper having public ip 62.19x.1xx.y8 and there is a corporate network behind a ISA server 2000 on 62.19x.1xx.x with all the clients of the corporate network running sjphone. However, eachtime I tried to register my sjphone. It keep trying to connect to the gatekeeper with a message like : RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; RCF|10.60.1.38:1720|aruna:h323_ID=12345:dialedDigits|terminal|8472_endp; And this RCF keeps on without the endpoints being registered. However, If I used 6x.19x.1xx.zz ip client (i.e. on public ip) it will allow the registration and call admission. Can someone overthere please help out. maruna The following is SJPhone.log 15:05:17 WARNING Registration failed: gatekeeper at 6x.19x.1xx.x8 is not reponding. 15:05:20 INFO Discovered status of local network interface 10.60.1.38 : 0 is Blocked 15:05:47 INFO Registering with Gatekeeper at 6x.19x.1xx.x8 as "aruna" (H.323 ID), "12345" (E.164) ... 15:05:56 WARNING Registration failed: gatekeeper at 6x.19x.1xx.x8 is not responding. 15:06:26 INFO Registering with Gatekeeper at 6x.19x.1xx.x8 as "aruna" (H.323 ID), "12345" (E.164) ... 15:06:35 WARNING Registration failed: gatekeeper at 6x.19x.1xx.x8 is not responding. 15:07:05 INFO Registering with Gatekeeper at 6x.19x.1xx.x8 as "aruna" (H.323 ID), "12345" (E.164) ... 15:07:14 WARNING Registration failed: gatekeeper at 6x.19x.1xx.x8 is not responding. -----Original Message----- From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Stewart Nelson Sent: Tuesday, January 18, 2005 12:26 AM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Re: how to improve intelligent nat handling Hi Tom, I'm glad that you got the Draytek working. A couple of comments: > i am not a developer but IMHO if this help (what it did) the gnugk can get > the answer from the first request at port 1719 (the registrations request) I think not. It's a good bet that the Draytek did substitute its public IP in the RRQ packet call signal address. You can run Ethereal on the GK machine to verify this. If so, then gnugk wouldn't discover that the endpoint was NATed until the first call in or out. Then, it might be difficult for the code to deal with the change. > isn´t it possible to trace the full packet anyway to see if > it´s really a public IP Endpoint or Proxy (the private ip address range is > well known) ? The "well known" range would be a good start, but it would need to be settable from config file. There are some reasons to use registered IPs behind NATs, e.g. 9.0.0.0/8 is registered to IBM but intentionally not routable on the Internet. It is also common to use private IPs without NAT. E.g. an ISP assigns customers addresses in 10.0.0.0/8 for voice and video (in addition to a public IP for Internet access). It has its media servers in 172.16.0.0/12, with non-NAT routing between networks 10 and 172. >> STUN could potentially help, but that solution would be of no use to >> the majority of users with hardware endpoints that are almost always >> closed-source. > agree with you maybe this is not for the endpoints but it could solve many > problems with a child/proxy GK to give more fault tolerance for broken NATs > and or broken Endpoints. If you have a static IP, then you should be able to set NetworkInterfaces on the child and accomplish most of what you could do with STUN. Have you tried this? [in 2.0.9; it seems to be broken in 2.2] Regards, Stewart ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/ ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id?49 Homepage: http://www.gnugk.org/
