Hi Stewart, thx for your answer please find my comments below. >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. I have done a trace with ethereal and found that the Draytek claims to be a public IP Endpoint so i guess that the Draytek is doing a rewrite of the signal address. I also can see it at the .log file with -ttttt that the client register with a public IP. >> 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. OK if I get you right, there is no chance to do a full automatic and the first possibility to realize that the NATed Endpoint is a faked public Endpoint is at the first call ( i guess at the logical Channel Setup) i am right so far? >>> 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] In most cases, at all here i Germany i have the Situation of dynamically assigned IP adresses, so maybe STUN could help to provide the gnugk with more Information. But if i understand right it would be more important to have the information at the parent GK (at the public IP) to do the Channel Setup the right way. Only a consideration. The parent GK could know that he has a public IP (maybe a configuration option or a comparison against a base for most common Public IP Adresses) A NAT Client is registering (could also be a normal Endpoint) and the Router rewrites the signal address and for that he claims to be on a Public IP Address. (till the first call) At the RTP Channel Setup there must be an association to the client Type "Public" or "Private". If a client claims to be a public client and send at the channel Setup a private IP (comparison against a private ip address base) something must be wrong and the gnugk can force a NAT Translation. (like the NATed Endpoint option but automatically) So there could be a configuration option to do automatic detection of faked (public) NATed Endpoints, do NO automatic detection (the situation now) and add/remove a private address range to/from the standard private address base. thx and cu TOM ------------------------------------------------------- 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/
