how to improve intelligent nat handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



hi,
i am new to the list and did already a search about the NAT Q&A but couldn´t find an answer for my problem right now.
 
we use videophones with the gnugk which works really pretty fine except some problems with several NAT Routers.
 
the most problem we have is that the phone can connect the outside gk with public ip and register correctly but at the channel setup the reply IP is setup as an private IP.
 
isn´t there a way to rewrite the IP at the channel setup to the correct IP, because the gk already knows the real IP of the phone behind the NAT (from registration) and the private IP´s are also well known. (i know that many SIP Provider will do this to establish connections with broken NATs)
 
i guess that some broken NAT routers try to rewrite the IP address at translation but don´t do it the right way or as deep as it is necessary for H.323.
 
e.g.
any phone or also a child gk behind a draytek vigor 2200X register with the public IP instead of the private IP at registration.
gnugk states a NAT=0 (did s.b. know what are the different NAT Types?) at the gk.log file with -ttttt
i assume that gnugk guess that the phone is without NAT or that there is no translation necessary.
as an result at the channel setup the reply IP of the phone behind the draytek router is an private IP which couldn´t obviously work.
 
it did not matter if i use dmz or portforwarding the result is always the same, the other side can here and see me but i can´t nothing receive at my side.
 
i could expand the list to some more routers e.g. some zyxel, dlink, netgear, devolo etc.this is because of the upcomming and at the moment mainstream broadband connections over ADSL with one dynamic IP (and a disconnection every 24h) not really a fortune.
 
also setting up a proxy gk as a child gk behind such a NAT router will bring some improvements.
(can i force the child (proxy) gk to be a NATed Endpoint?
 
could STUN which is already included in the openh323 protocol bring some improvment? Any hints are warmest welcome :-)
 
thx in advance
TOM
 

[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux