A stumper for the net gurus
 

We're trying to set up a new video conferencing system. It's behind a router doing NAT. The call setup isn't happening because port 1720 isn't reachable from outside our network. (inside it works just fine.)

Our ISP swears they are not doing any filtering.

So if our router isn't blocking this incoming connection, what else could be throwing it away?

Our videoconferencing system at home was *VERY* particular about what brand of router it would play nicely with. Turns out the Linksys that had been completely suitable for every single purpose for which I intended it was not workable for our VC setup. It had to be D-Link. I would not have believed it if I had not seen it with my own two eyes.

Additionally, I found it enormously helpful to have a separate public IP address for the video camera, which made it easier for inbound callers to find it. Essentially we have two networks here at home--the videoconference one and everything else.

What is the manufacturer of your VC gear? The NAT isn't a deal breaker. We've got that working here too. I think I need more info. Who are you trying to receive a call from?

Well forget all that. Due to the complexity of the videoconferencing issue and the way they can interact with routers & such I decided to reduce it to a simpler problem. Hence I set up a box with a web server listening on port 1720. And that is my current test... when we're able to load a http://dummywebserver.com:1720 from outside the network, then we'll plug in the codec (a Tandberg 3000) and see what's what.

Forget that video conferencing system. Have everyone meet in the park, Take a picnic basket... a little fruit...maybe some wine...enjoy. :rolleyes:

Steve,

The issue isn't just with port 1720. You're going to have to make sure that the port is open for both TCP and UDP on that port, as they may be using UDP.

Using the web server as a test will only show that TCP for port 1720 works :). They may also be using UDP.

Best way to check is maybe with nmap or another scanner.

We checked the UDP issue already (tho H.323 uses TCP there), and nothing was getting through there either.

The problem was solved with an upgrade to the OS on the Cisco router--something to do with this. It turned out that 1720 was the ONLY port that exhibited this behavior.

I loved the bit about the "hidden command." Reminds me of double secret probation. (I'm also a little miffed that I found this out myself while tech support droids at three different companies were insisting they had never heard of anything like this and I must have screwed something up. They couldn't tell me what, but they were all sure it was on my end.)