Im having an issue with 2 hosts running Cisco IP Communicators.
The 2 hosts can make voice calls fine but video is only one way. If I remove the nat configuration on the router on one side, and plug the host directly into the router; the video works fine.
any ideas on a solution for this issue?
I have tried using NAT with overload, as well as static nat and specific static nat entries to forward TCP and UDP port 5445 and 5446. Show ip nat trans shows that everything should be forwarded correctly but the host cannot see the remote site. The remote site can see the host fine.
Looking at the Video Advantage diagnostics I see what is potentially the cause of this problem.
The video source and destination ip on the remote site are correct. However, the source and destination on the remote site are not. The main site points at the address of the remote side before it has been 'natted'. The router does not have a route to the inside local address of the remote site therefore video cannot be delivered back to the device.
Has anyone come across a fix for this?
Do you have an access-list or CBAC on your NAT router? The NAT table should be maintaining a list of sockets/ports and internal IP addresses, so this should fly through unless something was impeding it.
The NAT setup is basically an access list with permit any any. If NAT is removed the call works fine.
NAT seems to be working fine the problem is that the control information (containing the source IP of the sender) sent by the IP communicator does not take into account for NAT.
So the inside IP address is sent out in an ip packet destined for the receiver (this packet gets natted). the receiver gets the packet but has no route back to the inside address. Therefore one-way video occurs.
I hope that makes sense.
Set up a static route that states that if a packet is trying to get to so-and-so network that it needs to be forwarded appropriately. It sounds like a routing issue.
Yes this would work, However seeing as the company doesn't own all the routers between the 2 sites (not to mention that the network may exist somewhere else in the core -- hence why NAT was used) its not that easy.
Its strange; The same problem happened with voice in IP Communicator before but, Cisco fixed it in recent versions. Why did they only fix the problem for voice and not video?
Yes, well, as the issue is a routing problem, you really only have two choices;
1)Have a discussion with all of the key holders and see how much trouble it would be to propogate the routes that you need.
2)See if a more recent version of the software addresses this issue.
I'm curious, is this an instance of two companies merging and the respective IT groups don't play well together? Why would it be difficult to have the folks at the other site make some changes?
Actually, I think the issue is a Cisco IP communicator programing problem. (We are already using the latest version)
It's more because the network runs through an ISPs network (I'm working at the ISP) and the solution the company has been sold is productized.
This means any changes/configurations made to it that are not already part of the product involves contract variations and $$
We'll probably end up making GRE tunnel between the 2 devices
I was just wondering if anyone else had a similar issue.
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.
Thanks for your reply,
sounds like that could well be the problem. do you have a URL to that document you mentioned?
The best "explanation" of the problem that I've encountered so far is here: http://old.iptel.org/ietf/firewall/draft-shore-h323-firewalls-00.txt
(It's a draft doc written in 2000 by someone at Nokia. Look at section 2.2.)
However, I'm not aware of a "fix" in the network layer. It has been addressed in the standard (H.323)--as it should be.