David,
The problem may not be in the network layer.
When H.323 calls build, the calling party information element (incl. IP address) is contained in the H.225 channels (RAS) and the H.245 channels/streams the transport the individual media streams between the receiving terminal and the calling terminal. H225 and H245 operate up to Layer 5. So, even though your lower layers are aware of and accommodating the NAT process in the IP header(at both ends) in the video call attempt, the private IP address of the calling terminal will still be contained in the calling party IE (info element) in the H.225 stream (Layer 5). In some cases, the call will build, and H245 (audio and video) streams will successfully pass from calling terminal to called video terminal. However, the H.245 streams from the called video terminal will still be trying to connect to the private address contained in the calling party info element. Often, the outcome is what appears to be a one-way video call.
If this is the case, there are a couple of things to try:
1. Cisco provided a patch for this in some IOS releases on certain platforms. (I have limited experience with it, and never saw it correct the problem.)
2. Assuming you have full cooperation between you and the far-end(s), build a static route that extends the private addressing both ways to the far-end NAT/firewall for all traffic between the two video stations. (Not terribly realistic, practical or flexible.)
3. Depending on the video end-points in use, you can implement an H.460.x-compliant session border controller between the two NATs. If the video systems are not H.460.x-compliant clients, then you would need to place an H.460 client between them and the firewall/NAT process to function as a proxy between them and the session border controller on the outside.
Check out section 2.2 of this rather dated document. To my knowledge the problem can't be resolved (very well, anyway) in lower OSI layers.
Greg Roberts
