> It seems that Mr. Stewart also comes from Hong Kong... He can't write but > he can type... Nope. Just a gwailo who learned a little Cantonese while living in San Francisco. > Last night I investigated my IP Phone and found my adderss of router was > wrong. After I make amandment, it did the control signal good and cool. I > can dial to others, and they can accept the call. This is interesting, because it shows that gnugk is not proxying as it should. The IP Phone will only send to its default gateway when it has a packet destined for other than its local subnet. If gnugk were working as expected, all traffic from the IP phone would be going to 192.168.0.1 . But, since the router address is being used, some packets must be destined for the Internet (or perhaps the GK's WAN address). It is not clear if the GK incorrectly decided not to proxy the call, or if some Windows component altered some signaling information to confuse the GK or the phone. See if removing the InternalNetwork declaration, which should cause the GK to proxy everything, makes a difference. > But the only 1 thing is, I cannot hear from another party (which is > outside the Internet, also NATed but with DMZ pointed to target > computer already), but they can hear me clearly! Well, if the GK is for some reason not proxying the RTP, voice packets from the phone, addressed to the destination party, will arrive there fine, but ICS will probably change the source port number. This will cause the returning voice to not be delivered. > If other party from outer call my NATed IP phone, although it connects, > none of the sides can hear other side... I don't know what's happening here. IMO, you should debug the outgoing call first. > When I use ethereal to monitor the 192.168.0.1 NAT interface, it shows > that all RTP are going from phone to gatekeeper, but none are going from > reverse direction. Is that causing the problem? What is the destination IP address of these packets? Then, look on the WAN interface. See where the GK told the destination endpoint to send the RTP (GK sends an Open Logical Channel Acknowledge). Also, see if any RTP is coming in, and if it is addressed to the correct port. If you enable "Allow outgoing destination unreachable" in the ICMP settings on your firewall, you should see ICMP port unreachable packets if for some reason the GK is not listening there. > Again, thanks to you all! > Yours sincerely, > Jason Chan --Stewart ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
