Frustration & heartache trying to integrate Cisco videoconferencing units

fogled@mizzou

Anyone else attempting to integrate Cisco videoconferencing codecs - namely the SX series - into AMX systems? I've done 4 of them now, and have had nothing but abject frustration. In one case, after literally months of working with Cisco TAC, including detailed conversations about what xCommands, and the timing of those commands, I am sending from my AMX system, and what other xCommands might help achieve desired system functions, I just got an email from the TAC person saying he was completely unaware I had the system tethered to, and controlled by, an AMX controller.

I called in my Cisco resale reps - WWT in this case. After spending almost 2 hours physically looking over the installation, suggesting the AMX was the source of all the problems, and recommending decommissioning the AMX system and using the Cisco with it's "In Room Control" feature to control everything, the WWT rep sent a follow-up email calling my AMX system as a C***n system.

Yeah thanks so much guys, for paying such close attention to the details on this issue.

So... am I just completely insane to try to integrate Cisco systems into AMX systems? Is anyone else doing this with any success at all?

Enelson67

Which SX series codec? if it is the SX-80 there are modules available on the AMX website that seem to be somewhat stable. Are there specific functions that are proving difficult?

ericmedley

I've had no big troubles with one exception: There are some SX80 models with not-so-old firmware that the SSL connection does not work. If this is your problem, you might check firmware on the Cisco.

fogled@mizzou

On SX-20's, I simply can't figure out how to log in over Telnet to control the damn things. I'm arbitrating a Telnet connection and getting a UserID and Password prompt, within the AMX controller, but no matter what I try with UserID or password (changing passwords on the SX20's, creating new accounts on them, etc. and using those in AMX code), they only ever reject the password. If I just use a Telnet window, no AMX controller at all, they just ask for a password which no matter what I put in is universally rejected. I would expect there to be some sensible fix to the login issue - as in "Change this particular setting in the codec" - but they never could come up with a solution to my problem. I eventually gave up integration completely; the systems are simple enough I can get away with, "Use the AMX panel for everything until you are ready to do your videoconferencing, then use the Cisco panel to control your conference."

The case with an SX80 is infinitely more complex. It's a 3-camera system with a SpeakerTrack system and a 3rd camera. I've got 2 displays hooked up to it through an Extron switcher. What I'm up against on this unit is the way it allocates video to the displays. The end result is that I can't get the right video to stay on the right monitors. Depending on prior status when it went to sleep, and how the cameras wake up, and when the computer signal is sent to the PC input on the codec, I might get the computer presentation on the front monitor, or maybe the back monitor, and then when the call disconnects, it either stops displaying the computer content, or more likely moves it to whatever display it wasn't on before.

The settings in the codec, for display configuration and video output "roles", appears to be ignored by the system. Every time there's any change in video signal status, that latest change - even if it's a disconnect and loss of video signal from the far site - gets dumped onto the front display, and pushes whatever was there (usually computer content) to the next display. I've gone completely mad trying to document the effects of changing these settings in the codec. It does one thing on initial wake, it does something different on every subsequent video signal change. It does a third and fourth different thing, rather randomly, if I've got the SpeakerTrack camera inputs set to anything besides "Manual".

My main beef with Cisco is not so much the way the units operate, no matter how maddening their semi-random video distribution logic seems to be; rather, I am incensed by their complete disregard / lack of knowledge / lack of care about helping me, as an integrator, integrate the system with AMX. Their only suggestion is to NOT integrate, but to throw away the AMX system and use the Cisco and In-Room control for everything (even though they simultaneously admit that even with In Room Control, the codec still won't do everything the AMX does, so there will still be two panels to operate to use the system).

richardherman

We've done a bunch of SX20's and some SX80's. Some troubles, mainly with multipoint connections, but nothing really big. Only used the TC firmware versions, not the CE and all were controlled through RS232 and used the AMX duet modules (various versions).

fogled@mizzou

The only control I'm attempting to exert over the SX80 codec is:

1) Wake up (xCommand Standby Deactivate);
2) Calling a preset (xCommand Activate Preset PresetId: 2);
3) Put it to sleep (xCommand Standby Activate).

Do I really need an entire module for just those 3 commands? I am not having any trouble talking to the codec from the controller; it takes the commands, acts on them, and provides an affirmative response, via it's RS232 connection. That's not my problem here.

I am having trouble getting the codec to consistently do what the client wants it to do: *always* show the computer video presentation on one specific display, regardless of call status. The "PresentationOnly" setting for the video output does not work; the codec still moves the presentation around from display to display every time any other video signal status is changed. It also refuses to automatically send the computer content on connection, but the big red "DO YOU WANT TO SEND CONTENT" dialog on the Cisco touchpanel, that they then have to touch to get content back on the display, and sent to the far site, is working OK for them.

I've gotten the codec and the configuration nailed down to the point where it does everything the client wants, *except* the auto-share on connect (not an issue); and keeping the computer video on the front display after a call disconnect (this is a problem). No matter what settings are present in the codec for monitor roles or configuration, when the call disconnects, it either stops presenting the computer content, or moves it to the other display, instead of leaving it presenting where it was presenting prior to disconnect.

Again, this does not, to me, appear to be an AMX control issue. It is a codec functionality issue. But, I can't get help on the codec function issue from Cisco; the only thing they will do to "help" me, is insist that the AMX is causing the inconsistent video display/allocation problems, and needs to be taken out of the system. I have, in fact, completely removed all commands to the codec from my AMX code, and even completely disconnected the RS232 cable. The WWT representative insists he can make the codec work the way the client wants, but he was unable to achieve that while he was onsite. He kept saying, "Oh we can absolutely do that," but, then couldn't actually make the codec do that, even with my AMX system disconnected from it. He later sent me an email referring to the AMX system as a Cr***n system, in the context of "here's how to set up the system to use just the Cisco for everything" (except multi-computer source switching and volume control).

Does that help explain my issues and frustration with these things, and Cisco TAC?

fogled@mizzou

I'm still running latest TC firmware, but they want me to upgrade to CE, and integrate the in-room control features. But, they want me to do so at my own time and expense, of course. The end result under their suggestion will still be a more fractured interface (having to use 2 different panels, multiple button pushes and navigation in sub-menus on panels), vs, the single "Start Videoconference" button on my AMX panel that, at this point, works great, until the call disconnects and the computer video jumps around or disappears from the displays when that happens. If I could just solve that one remaining problem, I'd be done with this. Feeling pretty done with it, as it is.

fogled@mizzou

Are you using the RS232-USB converters to talk to the SX-20's?

richardherman

fogled@mizzou wrote: »

Are you using the RS232-USB converters to talk to the SX-20's?

Yes we are. We currently use these from Aten. Work fine with the SX-20's.

a_riot42

Cisco...lol. I hear you. I had a meeting with their TS staff and a couple higher ups when Cisco gear kept failing, and they wouldn't assist. They had me chasing my tail for weeks, blaming AMX, me, wiring, the moon, the weather. I finally did their work for them and figured out what the problem was, made some test cases and sent it to them. Heard nothing back for weeks. Finally got a hold of someone there and they asked me if I did all my testing inside a Faraday cage. Of course not! Then all my testing was invalid, even though the issue had nothing to do with RF. We no longer sell any Cisco products.
Paul

vining

a_riot42 wrote: »

Cisco...lol. I hear you. I had a meeting with their TS staff and a couple higher ups when Cisco gear kept failing, and they wouldn't assist. They had me chasing my tail for weeks, blaming AMX, me, wiring, the moon, the weather. I finally did their work for them and figured out what the problem was, made some test cases and sent it to them. Heard nothing back for weeks. Finally got a hold of someone there and they asked me if I did all my testing inside a Faraday cage. Of course not! Then all my testing was invalid, even though the issue had nothing to do with RF. We no longer sell any Cisco products.
Paul

Yeah Cisco if F'd up. I use some of their SMB stuff, the same stuff AMX is selling for their video over IP, the SG series stuff and from the get go when that stuff first rolled out it was plagued with problems, you'd tell Cisco and wait, tell them another problem and wait, they wouldn't even clear out expired dhcp clients from their pools so once you hit your pool limit they would no longer had out addressed even though clients were expired for weeks. most of the bugs were eventually corrected but it takes a long time for them to realize they F up.

fogled@mizzou

richardherman wrote: »

Yes we are. We currently use these from Aten. Work fine with the SX-20's.

Sweet thanks for the confirmation!

fogled@mizzou

Thanks to Enelson67, I've finally "cracked the code" so to speak, and have figured out how to make Cisco codecs do my bidding. This is definitely a case of me having to defeat basic functionality/"Features" in the codec for my clients (it really is an unusual installation/situation). That's why so many of my interactions with Cisco TAC kept going nowhere. The key was subscribing to xFeedback events, trap for specific events, and force configure all my displays and share settings how I want them, based on state changes in the codec. I think I'm on my way now. Thanks!

feddx

This is why I:

1) ALWAYS make sure you control Cisco endpoints via serial communication.

2) Make certain I know what FW version the VTC Endpoint is, as Cisco changes their API when they update their FW. Awesome.

fogled@mizzou

Word on RS-232 to codecs, particularly because on my campus, the codecs are on a different VLANs than AV equipment. IP communications between a controller and a codec, inches away from each other in a rack, has to traverse multiple switches and router hops, bouncing all over campus in the process. Any disruption in the network almost anywhere on campus means an IP connection between a controller on one VLAN and a codec on another VLAN will get lost. RS-232 may seem antiquated, but it's simple and solid as a rock as long as you have proximity. I originally controlled all the Polycoms we had on campus via IP, but eventually switched communication on all of them back over to RS-232 because of constant problems with network disruptions resulting in dropped network connections. I'll deploy one of those USB-Serial devices if I need to control an SX20 in the future.

At this point I've pretty much burnt all my bridges, and then dynamited the bridge footings, with Cisco and Cisco reps. It's been a long time since I've gotten this angry with vendors about support.

I really appreciate everyone's input, it's been very helpful to me.

MLaletas

fogled@mizzou wrote: »

RS-232 may seem antiquated, but it's simple and solid as a rock as long as you have proximity.

I agree completely, it may be antiquated but i rather then the example that you gave. If its all on the same VLAN I might change my mind, and especially if its just a local switch in the rack that of course IP.

fogled@mizzou

After years of going around with our IT department about networking issues & port charges, we finally got the OK to put network switches in our AV cabinets, and finally got private VLANs set up on our campus for all our AV equipment. It's hard to even describe how much more stable our equipment is on local switches in our cabinet on a private VLAN, than they were on publicly addressable IP space and network runs from IT networking closets. Now when the rest of the campus network hiccups or glitches or goes down, our AV systems keep chugging away. A rare win in this technical arena!

ericmedley

fogled@mizzou wrote: »

After years of going around with our IT department about networking issues & port charges, we finally got the OK to put network switches in our AV cabinets, and finally got private VLANs set up on our campus for all our AV equipment. It's hard to even describe how much more stable our equipment is on local switches in our cabinet on a private VLAN, than they were on publicly addressable IP space and network runs from IT networking closets. Now when the rest of the campus network hiccups or glitches or goes down, our AV systems keep chugging away. A rare win in this technical arena!

you know, being a networking guy myself, This one issue has puzzled me for over a decade. I've never understood the resistance to VLAN-ing out the AV control/video/audio network. It is much more manageable and easy to deal with security issues. The very few times I've actually convinced the IT people to do this (and I can count the times on one hand) EVERY single networking problem went away.

IT people are notoriously under-staffed and over worked. It's no wonder they are a surly and heavily territorial bunch.

fogled@mizzou

ericmedley wrote: »

IT people are notoriously under-staffed and over worked.

Yeah it took them about a week after setting up our VLANs before they decided to give us admin-level access to their DNS system so we could manage all our own DNS as well, so they didn't have to keep doing that part for us. Three /22 (1024 addresses) subnets, we've burned up over 700 of those fixed IP's with our equipment, in about 6 months. Every big AV system we put in uses almost an entire 16-port switch. We end up segmenting our cabinet switch to handle 2 or 3 VLANs as well: Public, AV, and in the case of Cisco SX-80's with touchpanels and multiple Precision 60 cameras, it's private back-side VLAN.

At least our small Massio rooms can run with just the ports present in the SDX & DX-RX, those don't need a separate local network switch.

TUTech

The commands in the manuals aren't a 100% accurate. The best thing to do is log in with Putty and type "HELP" or question mark. It will give you a list of commands that actually work with that specific unit. I still have an issue with Duo Open, Duo Ready feedback.