Video advantage and NAT

Unanswered Question
Dec 18th, 2007
User Badges:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
david.mackill Wed, 12/19/2007 - 01:17
User Badges:

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?

shikamarunara Wed, 01/16/2008 - 16:09
User Badges:

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.


david.mackill Wed, 01/16/2008 - 16:31
User Badges:

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.


shikamarunara Wed, 01/16/2008 - 19:37
User Badges:

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.


david.mackill Thu, 01/17/2008 - 11:06
User Badges:

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?

shikamarunara Thu, 01/17/2008 - 11:21
User Badges:

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?


david.mackill Thu, 01/17/2008 - 11:44
User Badges:

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.

gsroberts Wed, 01/23/2008 - 09:15
User Badges:


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

david.mackill Wed, 01/23/2008 - 11:26
User Badges:

Hi Greg,

Thanks for your reply,

sounds like that could well be the problem. do you have a URL to that document you mentioned?




This Discussion