1. Home
  2. Cisco Systems
  3. PIX troubles H.323 even with fixup disabled

PIX troubles H.323 even with fixup disabled

We have some problems with H.323 videoconferencing in a private network segmented by various PIXen running OS version 6.3. Clients are Polycom PVX running on Windoze PCs, and the problem we are seeing is that clients in one of the segments cannot connect to those in any other segment. More precisely, the call is signalled but when the called party clicks on "accept" the call is not connected and the caller gets a "refused" message. This seems to be the normal behaviour if the connection traverses a PIX which still has the default "fixup protocol h323" settings in place, but we have double checked that all the PIXen in this network have no fixup protocol h323 h225 1720 no fixup protocol h323 ras 1718-1719 in their configuration, and with that, video connections work fine now, except for that one segment.

Any ideas how to troubleshoot this? (Without the trouble shooting back, if possible. ;-)

aTdHvAaNnKcSe Tilman

Reply to
Tilman Schmidt
Loading thread data ...

I hope this will help, but it seems as though messages from this one particular segment are being blocked somewhere along the line or, the messages are getting modified somehow. run ethereal on the Polycom PVX system where videoconfencing works fine on and then run ethereal on a system from the network that is experiencing problems and compare the packets.

-Chana Atar

Reply to
hanna.weiss

Are you sure it's not just the destination ports that need to be opened?

As it happens, I have today been playing with Polycom VC stations across a WAN link, and it is clear that the documented ports are WRONG.

This is where I was at with my access lists (before I decided to use other means to filter this traffic):

permit tcp any any eq 1720 permit tcp any any range 3230 3237 permit udp any any range 3230 3237 permit udp any any range 2438 2445 permit udp any any eq 1719 permit tcp any any range 5555 5574 permit udp any any range 2326 2405 permit udp any any range 2478 2480

This range seemed to work fine initially, permit udp any any range 3230 3237

But then I connected in some Tandberg VC stations, and the Polycoms started using more and more ports, different for each new call. The doco the software came with was useless.

Reply to
Arthur Brain

Arthur Brain schrieb:

Reasonably sure, because:

- The PIX is configured not to block anything between these two networks.

- The behaviour is completely different from what I observe when ports are blocked. (Blocked ports tend to result in timeouts, ie. a long wait before the connection fails. Here the connection errors out the very moment the called party clicks "accept".)

- The behaviour is very similar to what I observed in the past if the h323 fixups were active in a PIX the connection had to pass.

Yeah. That's why I usually determine the ports I have to open from the PIX logs, not from the app docs.

Reply to
Tilman Schmidt

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.