any known issues between VS8000 and Lucent bridge?

[cr8zyh0rse]

i have installed a VSX 8000, with a V.35 serial interface. it is running 8.0.3.

whenever the client is in a bridge call using AT&T bridge (28-port Avaya/Lucent bridge), they lose audio or video anywhere between 15 minutes to an hour in call.

Polycom tech support first said, it is an issue they are aware of and sent me the 8.0.3 patch. but there has been no change at client's end.

I have opened three separate trouble tickets (meaning this is the fourth codec that Polycom has sent me for same client). also, ran a thunderberd/fireberd test for the copper and it came out clean. tested the link from VSU to VSU running a BERT loopback. came out clean.

even changed madge ports and then the QRVX card, but still same results.

BTW, forgot to mention--they are absolutely fine and dandy in a point-to-point--it is only when AT&T bridge comes into picture, these hassles happen.

anybody with experience in VTC know of any protocol issues between VSX codecs and AT&T's 20-year-old Lucent bridges?

best rgds.

[tom9933]

Have you tried basic mode?

[cr8zyh0rse]

yes, i tried to hard-set the basic mode by going into the web interface. (261/711).

still, no go.

in any case, in a multi-point scenario, wouldn't the aud/vid protocols be controlled/determined by the MCU? and still doesn't explain why the VSX8000 should cr@p out only on AT&T bridge calls?

as a test, i even set up a bridge call with a test bridge (non-Avaya/Lucent--i checked) in San Diego. they sucked three of their end-points into the bridge call--a Tandberg, an old PT970 and a VSX7000. we ran it for about an hour and ten minutes, no probs.

thanks, tom.

rgds to all.

[USAFVTCGUY]

I had much the same issue with my system when it was first installed. I have much the same configuration you do, it took a few times to correct, but software seemed to fix it. No issues since. My understanding was the way the system exchangec CAPS with the lucent. The newer codecs cause problems for the old lucent.

[cr8zyh0rse]

I had much the same issue with my system when it was first installed. I have much the same configuration you do, it took a few times to correct, but software seemed to fix it. No issues since. My understanding was the way the system exchangec CAPS with the lucent. The newer codecs cause problems for the old lucent.


which software helped, USAFVTCGUY?

was it a patch or the 8.0.3 release?

thanks and rgds.

[tom9933]

I was suggesting trying Basic mode because that causes the VSX endpoint to drastically limit what it sends in a caps exchange. The idea is that some of data in the caps exchange causes older endpoints to get upset and sometimes not even connect. Since you are connecting but then dropping out then maybe this isn’t the issue. Since you’re running V.35 I wonder if maybe the issue is clocking related. Is the older bridge getting or providing clock the way the other working bridge is? I know when we did a lot with T-1’s we had all kinds of problems with clocking.

[cr8zyh0rse]

I was suggesting trying Basic mode because that causes the VSX endpoint to drastically limit what it sends in a caps exchange. The idea is that some of data in the caps exchange causes older endpoints to get upset and sometimes not even connect. Since you are connecting but then dropping out then maybe this isn’t the issue. Since you’re running V.35 I wonder if maybe the issue is clocking related. Is the older bridge getting or providing clock the way the other working bridge is? I know when we did a lot with T-1’s we had all kinds of problems with clocking.

well, tom, it is very hard to get a Telco to provide any kind of useful info. all AT&T keeps telling the client is that their bridge is receiving corrupt data from their (client's) end-point, or that sometimes their channels drop out. (yeah, fat lot of help that does me.)

I am also with you on the clocking issue. anyway, have escalated to Tier 3 at Polycom, for the second time (last time, they said run the 8.0.3 patch and it will fix it... but it hasn't). will post any updates. meantime, if anyone here reads/hears anything about VSX 8000 acting up with Avaya/Lucent bridges, pls post on this thread.

Main reason I asked if anybody has specifically encountered this with VSX 8000 is because I have five other perfectly fine working Polycom end-points (no VSX-es, tho) on the same Madge and they all haven't had issues since I installed the Madge 60 about five yrs ago.

[tom9933]

Yeah I agree telcos can make life very interesting. Curious but have you tried putting a VS4000 in the same location just to test? I’m thinking this might help to clarify if it’s a line problem or a codec problem. I know the VSX acts differently on V.35 because I could never get a VSX to work with the FVC V-Rooms where as a 4k worked like a champ every time. If Polycom can fix this with a patch great, but it sounds like there may be some line issues.
Good Luck :)

[cr8zyh0rse]

thanks for the headsup, tom.

yeah, i already suggested my employers to consider loaning our lab iPower or the 4K for a month to see if they still experience call drop-outs. my guess is that they may not experience any call-drop issues--which brings us back to Polycom's R&D folks. unfortunately, they release products without getting the kinks out--just like VSX 7000, which had some serious issues that we had to point out and they flew in their big guns from Atlanta to look in and finally accept that the product didn't deliver.

but all this is moot, since my employer will not loan lab eqpt out. so once Polycom third tier fails to fix the problem, i will ask Polycom itself to do this. after all, the other five end-points that work just fine at same location on same Madge are also Polycoms. hopefully, they will agree.

best rgds and thanks for the tips.

have a lovely new year.

[cr8zyh0rse]

ok, the latest on this one:

Polycom is coming with a hotfix specifically for this issue.

The tier 3 support guy says they acknowledge a problem with the frame timing and also the recovery from timing errors in the VSX firmware. He said there are few complaints from customers using the serial interface and dropping outgoing audio and/or video at random intervals, and this new fix is supposed to resolve that problem.

Still waiting for the actual hotfix, tho.

Will update.

Rgds.

[USAFVTCGUY]

Excellent. I have started to note these audio issues as well. I look forward to this hotfix as well.

[cr8zyh0rse]

the hotfix seems to have fixed it.

will continue to monitor and post updates, in case same issue recurs.

the hotfix was obtained directly from Polycom engineering, after escalating case to Tier 3.

rgds.

[USAFVTCGUY]

Can I get your POC at Polycome. I would like to try this hotfix as well.

[tom9933]

That’s great news! Thanks for updating us.

[cr8zyh0rse]

Can I get your POC at Polycome. I would like to try this hotfix as well.

i initially worked with Jim Pennock in tier 2. then it got escalated to tier 3 in Atlanta, and a bunch of ppl worked on it from engineering. IIRC, Rick Ottinger was our POC to interact with that team.

hope that helps.

rgds.

[USAFVTCGUY]

Got it. I know Rick and will give him a call. Thanks

[USAFVTCGUY]

Hows, that patch holding up? I am trying to get a copy of it myself and see if it fits the bill. Let me know. I am working with Wes Cambell on this right now.