Polycom Real Presence issue

[darren_g]

Hi (it's my day for asking questions, it seems).

We have a client who desires that we connect to a Polycom video conferencing system using some software called "PolyCom Real Presence".

The trouble is - it doesn't work, or works intermittently - sometimes video works and sound doesn't, sometimes sound works and video doesn't, sometimes it doesn't work at all.

The remote end is trying to blame our firewall for the connection difficulties, but I'm 99.9% sure this isn't the case because I've done the following

1) Put a temporary blanket rule into my firewall allowing any/any on any port out for the node IP we're trying to test with

2) Plugged the thing into a stand-alone ADSL service *without* a firewall on it - only a router and NAT

Has anyone got any experience with this software so I can look for "gotchas" to try and conclusively prove that the issue isn't my end?

Thanks.

[jvalentine]

The only other thing to try would be an AppOverride.  This has the effect of disabling the SIP Application Layer Gateway.  You can read about how to use one here:

-

Not sure if that's going to help, though.  If #1 didn't work, but #2 does work, then the AppOverride will most likely help.  In any event, give it a go and see what happens.

Good luck.

[darren_g]

I'd rather avoid another App Override if I can - I don't think it'd work anyway, since number 2 in my list exhibited the same problems as number 1 did.

I'm just grasping at straws, trying to see if there's some trick to making this steaming pile of.....product work with a secure environment.

Thanks

[jvalentine]

Well, if the AppOverride doesn't work, then I'd point the finger back at the other end.  That's what I would do. 

[ericgearhart]

The biggest gotcha with Polycom VTC devices that I have dealt with involve the device itself not being 'aware' that it is being NAT'd.

Our CheckPoint firewall (our current edge firewall) actually recognizes the H.323 traffic coming from our VTC devices, and rewrites the IP address in the actual packets themselves to reflect the public IP address that our VTC devices are hidden behind. You can see this happening or not happening if you get a packet capture of the device and look at it in Wireshark - the built in Wireshark decoder shows the IP address the client "thinks" it is coming from.

If you placed the device behind a DSL modem and a router this wouldn't fix your problem... the VTC device would still "advertise" itself as being behind a privately routable address, not the public IP. Even if the remote VTC device receives the traffic, the remote device is still "dumb enough" to try to connect back to the inside IP address of your Polycom, not the NAT'd IP you actually came from. This is kind of hard to explain without a whiteboard... I hope you follow what I'm saying 😕

Are there any settings on the Polycom where you can explicitly set a public IP address that should be "advertised"? Then you could statically NAT the relevant ports on your Palo Alto back into your VTC device, for this one particular remote public IP address that you're trying to establish a VTC with.

I fought with this for a couple of weeks, a few months ago, so a lot of the problems with VTC are still somewhat fresh in my mind.

[darren_g]

Trust me, I already have. 🙂

[darren_g]

The problem is the VTC device isn't ours - all we have is the dopey software component (RealPresenceDesktop) - the actual Polycom device is at the other end (and, annoying, in another state, so I can't just lob over and smack them upside the head while saying "hey mate, THIS is what you need".

I found an old discussion on here which strongly suggests what you're saying (and what you're saying seems to confirm the older post) that the issue is the dumb device at the other end, not our end - especially when you consider the justification for the other end saying nothing is wrong is that they "Can make calls internally fine".

Huge red flag for me, based on the older discussion (and your comments) says they've got it configured with an internal IP address, and it's being brain dead with the NAT'd stuff.

What I may have to do is run Wireshark on the PC we're testing from, try to capture the traffic during testing, and then use that to ram down their throats.

Cheers.