MCG-100 and V-tel

[mumpwife]

We have a MGC-100 bridge and lots of other remote sites with V-tel Galaxy 2.2 or Polycom VX4000 units, which connects to our bridge. They are all connected to us through T1 using IP(internal).

The problem that we recently have is that sometimes, the bridge shows sync losses going up only with V-tel systems. For V-tel site, they don't see any problems with audio or video, but for other sites to look at V-tel site, the V-tel site freezes really bad-no audio problems.

At the same time, when I look at their router, which directly connects to the v-tel unit, their CRC errors are going up as the bridge sync losses are going up. And their units and routers were hard set to FULL-duplex with 100mb/s.

Was wondering if it's something to do with MCU, V-tel or network...

As you can tell, I am not experience in video, only less than a year now. Thanks....

[JNicotina]

The problem actually exists in the VTels. They do not communicate well via H.323, especially when connecting to a different vendor.

We had the same issue here hence the reason for swapping out our entire VTel network (In regards to Codec's) to Tandbergs.

If you monitor a VTel system (And when you say VTel running 2.2 I assume you mean Galaxies) while connected in an IP call you will notice that their FUR (Fast Update Requests)count is climbing very quickly. We determined that these update requests were causing severe packet loss which heavily froze and degrated video. We noticed that this issue was not present (Or at least to a point where it ws creating issues) when we connected point to point with another VTel. It was only an issue when connecting to a different vendor or a bridged conference through the MGC.

[mumpwife]

Thanks for your info. That's what we were thinking. We recently got rid of lots of v-tel units to polycom and eventually they will replace all ther rest of v-tels. thanks

[Talon Oak]

I have spent the last 12 years working with VTEL systems starting with the Media Max. When the Galaxy was first introduced and connected to an IP network there was some freezing in the video and the only fix at that time was to set the IP precedence (QOS) in the network to allow the video packet priority over all other packets. When it was connected to the Accord MGC-100 it was discovered that the packet size used by VTEL was the maximum packet size allowed by the IP standards where the MGC-100 used a smaller packet size.
Keep in mind that the minimum and maximum packet sizes were a range that was set by IP protocol standards and were only a suggestion, so both VTEL and Accord were correct and within the standards.
Quite a bit of time was spent in a lab evironment at Accord in Austin troubleshooting this and finding a happy medium. Unfortunatley, without a Gatekeeper this problem kept croping up and was never really solved.
Several customers who purchased the VTEL Galaxy system were not happy with it when it was connected to an IP evironment although it would work quite well in an ISDN evironment. That is, after they got away from the idea of running each Galaxy as a server and the VTouch software as a server application. When they finally re-wrote the Galaxy software to run as a Windows application it ran much faster and smoother.
Vtel end of lifed the Galaxy system approximately 2 years ago and have brought it back as the Vista Pro. The software has recently been re-written again to run on Windows XP, or if it hasn't been re-written yet it will be soon.

[copelandjr]

I would take a look at the speed and duplex settings on both the galaxy and the switch... Per the ethernet standard if the switch is hard coded 100 full and the VTEL is set to Auto, it will negotiate half-duplex and vice versa... Set them both the same (Auto Auto or 100 Full, 100 Full) and your problems should go away. The new Vista line is running the latest H.323 stack, but will have the same problem unless you pair the speed and duplex settings. This is true for all H.323 Videoconferencing manufacturer's equipment. With Cisco switches, I recommend Auto Auto with no technical reason, it's just what seems to work the best. Another troubleshooting technique would be to put a small 4 port switch between the end-point and the switch.