Hi Benjamin,
This could be a problem, since B1 (behind the uncontrolled NAT) is the one who can't be reached by UDP. Unless the B1 client can be made to send UDP packets to the GK or A-client first, and the B-NAT is stateful with respects to UDP (which might take some time to check), I guess using a proxy on the A side makes little to no difference. As I'm neither an expert in NATs nor in H.323, I'm not even sure whether this can be done.
It works ok in nearly all cases. If the NAT is ignorant of H.323, the GK will see private addresses in the RAS and know that B1 is behind a NAT. Then, when ProxyForNAT is on (which it is by default), GK will send A1's voice packets to the NAT on whatever port voice packets from B1 are coming from, even if the logical channel negotiation said otherwise. The NAT is almost certainly stateful enough to get the packets back to B1; it appears just the same as a DNS query, NTP request, etc. As you said, this doesn't work until B1 sends RTP, which won't happen until it sees the Connect. That's a problem when calling the PSTN (can't hear "number has been changed" announcements, etc.) but should not cause any trouble in your application.
If the NAT is H.323-aware, it should translate the port numbers and open those needed.
In the meantime, we're asking the B-side NAT admins if they can arrange a GK on the B side,
but this will take some time.
It may be easier to just get them to set up a few port forwards for you.
--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/
