Can only connect at 320k?!? Then call drops?!?

[nick6262003]

Hi all....I have a few questions, hopefully someone can answer. There seems to be a lot of good info going around here so it compelled me to post my technical issues.

Let me start by saying I'm new to the technology. My company had a system since I got here and since I am IT, I got the responsibility of maintaining and troubleshooting it :) It is a Tandberg 6000 and has worked rather well. My question is...we don't seem to be able to connect any higher than 320k (max is 384k). I connect fine to the Tandberg test site at 320k but most other sites I attempt to connect with establish a connection (at 320k) but drop right before "negotiating audio/video quality"? Tandberg isn't much help because we now own the equipment and don't have a service contract anymore.

Alternatively, if anyone knows a good site that can get me up to speed with the different technologies or how to troubleshoot connection issues (aside from the obvious, is it plugged in, do you have a sync on the nt-1). That would be awesome. Thanks for any help you guys/ladies can give me.

[pbraatelien]

A couple of things you can try:
Do you know who your long distance carrier is?
Try using a different pic code when you dial-(1010333 or 1010222) your carrier may not have enough 64K channels
How about inbound calls? What data rate can you receive?
Is the Tandberg set for 384K?
If you need someone to try and dial your system, let me know.
Paul

[nick6262003]

Wow, thanks for the response!! I do not know what a pic code is but I will go research that...sound like a possible lead?!? Yes, the same thing happens when someone is dialing in to me. And yes, the Tandberg is set to 384k, or Auto, I've tried both. No matter what though, it only goes to 320k?!? Sprint is our long distance provider, maybe I should start with them. Or should I start with Verizon, the "local" provider?

For my second question...do you know what might cause the dropped calls like I'm getting? Is it an incompatibility between the two machines? errghh, It's frustrating to not understand how the system works "fully". I consider myself a technically competent individual....but theres no documentation and this is the first community site I've been able to find that offers any kind of help. You people are the best!!

[tonyi]

Want to try Dialing the Call restricted. Tell the tandberg to restrict to 56k. Also when connecting check your channel status to see if all 6 channels are connecting or if your getting an error code on any of them. If so you might want to talk ot your network provider or ensure you have the lines set up right.

[mazzarak]

I would say its not likely to be an interoperability thing, as Tandberg are very rigorous about making sure that their kit connects to others. Its true to say though that Tandberg 2 Tandberg is likely to be more sturdy, hence its staying up on 5 channels instead of dropping like others. Are you on 3xBRI or 1xPRI ISDN? If you have 3 different lines, you could try each line individually at 128k and see if any of them mess up.

You will also be relieved to hear that Tandberg have a quite active and always helpful presence on this forum, so they may have some specific things you could try. As Paul says, there are plenty of people on here who'd be happy to do some ad hoc troubleshooting with you. To at least help you figure out what it isn't! (which is half the battle ;))

[dfreeman]

Sounds like a D channel issue, make sure your IXC is trunking you through data capable lines.

[Gary Miyakawa]

I believe my question would be, is the system that you are calling willing to accept (and negociate) an odd number of B channels ? If you placed the call as a 384kb call and one of the B channels fails, will the recieving system downspeed. I know that all the current major systems (Tandberg, Polycom, etc) will downspeed, but the older Concordes won't typically downspeed.

You should be able to see which B channels have connected and based on that, tell the telco what line is giving you problems.

Gary Miyakawa

[WIZBANG]

Best way to troubleshoot that type of issue is to have another CODEC make 2X64K calls to the individual ISDN lines(unless provided by a PBX, each ISDN should have 1 number per channel), 1 ISDN line at a time.

If any ISDN line will not complete a call on just that ISDN line, start a trouble ticket with your ISDN provider for that line, explaining that 1 of 2 channels are not working and how you arrived at that conclusion.

If all the lines work individually(2X64), but not together at 384K, there may be a bandwidth bottleneck somewhere on a trunk. Also requires a call to the ISDN provider but takes more tracking to find where the bottleneck is.

Paul

[MichaelG]

Yup....go with the wizbang thing. Test each BRI one at a time,should narrow down the problem. Contact your LEC most soonest. There are certain parts of the country where its hard getting a constant good connect.

[nick6262003]

I can't say enough how much I appreciate all your help. I did as Wizbang said and tried each line seperately. On the 3rd line (the one thats giving me problems) I can only connect at 64k. When I attempt to dial that number it gives me a error code 41 (temporary failure). When I attempt a 384k call, all lines connect fine except for that last B line which stays at idle. I'll give the phone company a call now and go from there. As a side note, we were having issues with this same exact "pair" not wanting to sync on the NT1.....I guess they haven't quite fixed it?!? Again thanks for all the help, its been an valuable resource. :classic:

[WIZBANG]

Happy to help, and glad the testing narrowed down the issue!

If a provider has trouble fixing a specific ISDN line on a continuing basis, it may be best to order a new ISDN line and use it to replace the troublesome one. After the new ISDN is in and working, cancel the bad one. This is an extreme solution and should really only be used if the provider is unwilling or unable to fix a line. You must always have a backup plan in this industry.

Paul

[vtjoe]

Before calling the telepone company (telco), make sure there is absolutely nothing wrong with your equipment - which includes internal wiring, NT, and the codec. You are at an advantage because lines 1 and 2 are working, so you can test the codec and the NT pretty effectively.

Everything about 56K restrict, PIC codec and calling individual numbers is good advice. Here is my $0.02 worth...

1) Something really simple, double check your phone number and SPID (if applicable) for your third line.

2) Your NT box might be bad on the third line, or it could be internal wiring. Since you can place a call on lines 1 and 2, try switching line 2 and 3.
From the wall (U -interface) to the NT, switch ports 2 and 3, then from the NT to the codec (S/T interface) switch ports 2 and 3 again. This way you don't need to reprogram SPIDS.
If the problem now happens on line two, it was your NT box. If line 3 is still bad, it could be the internal wiring or it could be the telco. If you replace the NT, make sure to replace the power supply, as there is a good chance the power supply was the problem in the first place.

3) Swap out your CAT5 patch cables for line 3 and test.

If you are convinced it is the line (which it probably is), call the telco.
When you call the telco, the first thing they are going to do is deny that it is their fault and they will blame your equipment. The next thing they are going to do is a BERT test. If that comes up clean (and it usually does), but your system is still not working your screwed. At this point, I would take WIZBANG's advice and order a new ISDN line, once it is working, cancel the other one. Unfortuntely you need to get an ISDN line in the same trunk group and the same exchange (e.g. in 202-555-1234, the 555 is the exchange). It is not always necessary to get the same exchange, but it is more likely to work. However, these phone numbers might not be available.

This brings us back to the BERT test. A BERT test is just a series of ones and zereos that test the integrity of the wire from the telephone companies central office switch to your NT. However, it does not test any of the programming at the Central Office telephone switch - which can be totally messed up, but nobody will look at it until you prove to them it is their switch. Depending on which telco and who you are dealing with, this might be an impossible task. At this point, you need to say "See my setup in the translations for line 2 (whatever the phone number or circuit ID might be). Make line 3 look exactly like line 2." If they say it does, then ask them to humor you and erase the setup for line 3, then rebuild it to be similar to line 2.

However, the happy magic thing about opening a ticket with the telco is that sometimes the problem magically fixes itself, and the telco tells you nothing was ever wrong. It is a little trick they play. If the line was never down, then you can't ask for your money back for the months you were paying for a service that never worked. Good luck.

[nick6262003]

Well, thanks to the advice of the last two posters, I was able to get the Telco (verizon) to fix the problem. They INSISTED it was my hardware but I explained over and over again that I have tested with different NT1's and switched the SPID assignments on my VTC unit and the problem followed. After the sent out ANOTHER tech to verify the wiring (which was fine, again), I insisted that he called their programming office rather than I. It was quite ammusing, as he had them on speakerphone, to see how much of a runaround their own techs get (its not just the customers). After way to many redirects we finally found someone who knew what they were doing. I got a call back a few hours later and it turned out to be a "translation error on the switch". Wow, imagine that. I just wanted to say thanks again. You guys/gals have been a valuable resource in helping me troubleshoot this issue. :D :D

[robertk]

I was able to get the Telco (verizon) to fix the problem. They INSISTED it was my hardware but I explained over and over again that I have tested with different NT1's and switched the SPID assignments on my VTC unit and the problem followed.

Been there and done that for eight years now... I'm quite good at babytalking to support-staff at telcos nowadays :^)

//Robert