MGC100 sync losses

[mazzarak]

Anyone have any experience with working out where l-sync and r-sync video losses occur on an ISDN connection. e.g. which layer they are occurring on? We are making connections from Germany to the UK at 384k and getting massive errors on them, yet the bridge shows no NET errors and nor does the network.
Any remote way I can see what layer the errors happen on? Or is it frequently a specific layer that it happens on?

[Glen Sykes]

I'll do some digging and post later.

In the interim, have you tried routing the calls over a different long distance carrier?

If you have and the problems remain it is likely that the problem is local to the German side.

[mazzarak]

thanks Glen,

the problem is we can't get another carrier in place, as we are in a co-locate for our current carrier. In fact it seems it'll be quicker to get a loan of another bridge...

Andy

[trapehzoid]

he means simply dial via PIC code to another carrier. I think even on a LD carrier provided circuit you can still PIC to another carrier.

[Glen Sykes]

Exactly Trapezhoid.

Mazzarak,

If your carrier is BT, it is a simple process to route your calls via an alternative carrier with the dialling of a prefix. Cable and Wireless for example can be accessed with the prefix 132 (although you'll need to have an account with them for this to work). BT are obliged by OFTEL to support alternative carriers via their physical circuits via indeirect access. However carriers such as NTL do not support indirect access.

You shouldn't need to install any additional hardware as the routing is taken care of in the exchange.

It's also worth noting that some carriers will actually re-sell BT international bandwidth, rather than having their own interconnects. Given that, it's useful to be selective about who you choose for your alternative routes, as you may end up with even worse service than you currently experience!

[mazzarak]

Hi guys

thanks for your thoughts on this. We are on Colt, and what is puzzling is that from one bridge in Frankfurt to another in Amsterdam stays on COLT throughout and has faults, but the Holland network is definitely stable to anywhere else.

In addition to this, connections within the city of Frankfurt, to customers that are also on Colt, are just as bad, ruling out international carriers.

It's all a mystery...

[Glen Sykes]

Hi guys

thanks for your thoughts on this. We are on Colt, and what is puzzling is that from one bridge in Frankfurt to another in Amsterdam stays on COLT throughout and has faults, but the Holland network is definitely stable to anywhere else.

In addition to this, connections within the city of Frankfurt, to customers that are also on Colt, are just as bad, ruling out international carriers.

It's all a mystery...


Well there's one plus point to be taken from this and that is you have a single owner of the network that you can work with. What do COLT have to say about this?

[Marty Marlow]

mazzarak,
how are you set up to recieve clock to your MCU and other equip in your network? Please explain your current configuration. Sync loss errors normaly indicate clocking problems. Please Give me as much info as possible.

[Glen Sykes]

mazzarak,
how are you set up to recieve clock to your MCU and other equip in your network? Please explain your current configuration. Sync loss errors normaly indicate clocking problems. Please Give me as much info as possible.


I doubt it's clocking on the MCU side as Mazzarak pointed out in the 1st post that the problem only occurs on calls to germany, although saying that he didn't say what calls were like to other destinations.

Mazzarak, can you clarify?

[mazzarak]

last time we tried, there were issues dialling in to the same ports, but its all got so confusing now that we are 99.9% confident that it's not the Accord. This is mainly due to the fact that we have an old Ezenia for just such occasions sitting in the same Co-lo, with (minus any great diagnostics) the same errors. The clocking is received straight off the circuit, so I'm told, and we've moved the clocks around and various other things. I now have a man in Berlin tearing his hair out...

[Glen Sykes]

If i were a betting man, I'd say it was a COLT problem.

[Skylark]

I had the same problem with an MGC-25 when I called to som foreign countries but it worked fine localy (cloclk was fine).

It turned out to be our PRI-ISDN provider (somthing to do with compressing the lines), we changed to a diffrent service provider and the problem was gone.

[mazzarak]

currently they think the fault was actually on the COLT GPS clocking, so we are testing again today - all a bit weird...

thanks for the feedback though!

[Marty Marlow]

what kind of Imux are you using can you send a drawing of your setup. Are you using crypto if so what, Kiv 7,19,kg194's. Are you using r366 isolator need more info brother.

Glen Sykes. dont be so sure of your self. Little things make a big diffrence. I deal with this everyday and I have seen worse.

[Glen Sykes]

Surely if the problem was local to the MCU as you describe then the problem would be global rather than isolated to germany?

[mazzarak]

yeah, perhaps I didn't explain it too well. The fault is certainly no longer there, but it did apply to all calls made on bonding.

We suspected, and took you guys advice, that there must be something in the clocking that wasn't right, and in the end they said that the GPS clock that they were referencing themselves was faulty. This is either extremely dodgy, or extremely unfortunate, but either way they seem to have solved it about 24 hours before we walked.

It was odd because all our circuits were affected to all locations, and the proof we had was impossible to locate as the MCU doesn't give off huge amounts of logging files. (I'm in the UK and the fault was in Frankfurt, not convenient for checking it out for myself)

But as I say, that seems to have been it, thanks for rallying round and sharing the knowledge - what this forum is here for! :)

[abakar]

If i were a betting man, I'd say it was a COLT problem.
can you try to connect at 336, if you you geting problems, call your service provider to ckeck the ISDN line.