Had a job where I installed a Cisco/Codian 8510 MCU. This is the large blade based system. In this case the customer had purchased the firewall option which allows one to enable Port B on the system and assign it a public IP address. Along with their webconferencing license, they thought they could use the Codian’s ConferenceMe feature to allow outside users to participate in conferences even if they didn’t have an endpoint or a desktop client. The network looked something like this:
ConferenceMe worked fine on Port A. However we could not get it to work on Port B. I had setup ConferenceMe on Port B in previous configurations, so we set out to see what was the problem. In the logs of the MCU we saw the following:
This was the same on every failed connection: Tunnel Socket, Connection closing unexpectedly, Destroying tunneled connection. I won’t get into all the details of the logs and packets that were captured, all the things that were tried, software that was updated, etc. But the most effective troubleshooting boiled down to:
- Use a laptop to connect to ConferenceMe on port A (to make sure that there was nothing wrong with that PC re ConferenceMe). That worked.
- Use same laptop with a cross over cable to connect to the MCU directly on port B and connect via ConferenceMe. That worked !
- Use same laptop to connect to their main VLAN switch and connect to ConferenceMe. That also worked!
- Tried to backup to the next step in the network, but was told that the parent company controlled that and there was no way to get help from them (ok? great parents!).
- Captured packets from when the call worked and didn’t work as well as the event logs (in the above testing), and sent those files to Cisco TAC as per their request.
- Note: I also tried to change the ports for web and tunneling on the MCU port B in hopes that would have some impact, but it did not.
So, I was somewhat dumbfounded when I received the following from the support engineer at Cisco/Tandberg today:
“I checked with the escalation engineer and we checked with R&D regarding this issue. Unfortunately ConferenceMe is not supported on Port B until the next software release 4.2. We tested the same on our network and found similar issues while having conferenceMe on port B. The current software release itself is not fully supportive of handling conferenceMe on port B. R&D have looked into it and we expect for this to be supported in 4.2 release which maybe probably around mid June.
Please inform the client about the same and let me know the opinion.”
I wrote back that I thought in my opinion, the customer would be pissed off.
One of the biggest frustrations of being a field engineer is that you have to be the one to tell the customer that their new solution will not work the way that the sales engineer said it would. Interestingly enough, those guys are never around to take the blame for their designs. Oh, well. Lesson Learned.
Related posts:
- Installing short-throw Projectors in rooms with low ceilings.
- UC/AV/VTC integration and the future of the videoconferencing market
- Load-Balancing Switches: Bad for Video Conferencing
- VCS Starter Pack, the Missing Step
- Lessons from a Pathfinder Install: Part I
- The Seven Blind Men and the Future of Unified Communications
- Why do VTC makers lie to themselves and their staff?
- Checklist: Basic VCS Expressway Security
- Revolabs Mics: Fixing the “Garbled” audio problem.
- Filemaker Database for Tracking Service Contracts
- Radvision Interop: from desktop to telepresence.
- How does technology-related anxiety affect educational technology adoption?
- Ninite: One Installer to rule them all
- Check out the WP Random Header Plugin
- Off forming a new company: VTCStream.com
