PDA

View Full Version : BRI Long Distance Conecting Problem


BirdVTC
03-16-2005, 03:02 PM
I am a TANDBERG 6000 Codec user, with a BRI / six channel 384 kbs circuit. My issue is I can dial out on local calls and connect a video signal, but my system will not connect a video call using long distance. The long distance call (using a ‘1’) does work, but only connects as voice/phone not video. If I use no '1' before the number no call is started. Verizon is the BRI carrier, and MCI long distance, which I have called on this issue. Both companies tell me there is no problem with the carrier or voice/data circuit. This problem started when we changed addresses and BRI numbers/line. Any ideas on what my solution or setting changes could be? As a note, my IP connections work all the time, and people can connect to me using long distance ISDN lines.

Need Help BirdVTC

carolyn
03-19-2005, 03:22 AM
I have become an expert at this ..not by choice...repitition both on the service side and now as an end user. The telco will always give it right back to you. A couple of questions:
1. Is this a new install/new ISDN?
2. Whoever the personis thaty orders this service...did they state in the order to name a long distance provider? ATT, MCI, Sprint..

Your local telco is supposed to set up the "hand off" at their switch but the LD is supposed to have you set up too. it can be a battle. the easiest way to test for local vs. long distance..call a local site then a ld site..that is obvious. But as an added bonus to prove your problem...dial the number manually BUT use a PIC code before the number. As a mattter of fact I just did this test yesterday for a system experiencing the same problem. Putting the pic code in worked. Now I take that info back to the telco and then the fight goes on....you must also include a call to thje LD provider too...(if it different from your local). There are three basic PIC coides...mci, sprint and att. I can't remember them all or who represents what pic code....i just always use 1010222 then 1 area code and number. You can also use 1010288..I forget the other. Another tip..I have even seen where our first line connects fine w/no code but never can get higher than 128. I put a pic code in and then i get 384. some of the lines were dropped by the ld...Please know that you should not use a pic code as a solution to your problem in the long run...if your organization has an agreem,ent with one of the carriers...and you usew a pic that doesn't match or even if it does..any special "per moinute" charge will not reflect any special cost that your org may have. Lastly, using a pic code can also result in your "auto changing " the ld carrier you may have prior to your problem if the pic code you use fdoes not match the one for the ld carriewr you have. I have seen this and even got a phone call once from telecom group because they got a bill for ld thaty was not our carrier. Therefore, I only use them to prove my point to the telco...and it does work in getting them to listen yo for you.

good luck!

VTCZealot
03-19-2005, 01:02 PM
1010333 Sprint
1010222 MCI
1010288 AT&T
(Note about AT&T's PIC: I will usually not work unless you have your numbers registered with AT&T with a billing account. The other two should work fine regardless unless there is a problem at the local handing off to any LD Carrier.)

VTCZealot

Joe Vallender
03-21-2005, 02:24 PM
Could be that if your first call is not routed over clear channel circuits, the data is being corrupted and all that can be supported is a voice call. I've found that when specifying a LD carrier, the customer may not have clearly said that video/data was being used. The MCI voice network PIC code 555 was used and that will not carry data calls. Did you have a ticket # with MCI?

Maybe I can help as I assist our LD techs in troubleshooting these type of issues.

vbhere
03-21-2005, 02:28 PM
Speed............

I would try forcin the call on 56k trunks. If there are not enough 64k-trunks to support your it will not fully negotiate. Try 112,224,336k speeds.
You might also want to try a 2x64k call.

If this does not work then its definitely an issue with the IXC.

damen
03-29-2005, 12:32 PM
I am in the middle of an almost identical problem.

Verizon local carrier, MCI long distance...

384k calls, BRI's, the whole works.

Local calls works fine.

Long distance connects at 384, but outgoing audio cuts in and out (out more than in). We transmit an insane # of errors. At 256k, no problems. However, at 384, we CAN connect to the MCI test sites that are long distance (and yes, we have tried multiple sites that werent MCI that are long distance and dont work).

MCI says no errors on their lines.. Verizon says the same. Started approx. 3 weeks ago. Not a new installation, these sites have been working with us at these speeds for the 3 months I've been working here, and my understanding is this facility was used with those sites for a few years.

MCI and Verizon are both stumped.

dfreeman
03-29-2005, 07:57 PM
Check that the IXC is trunked over data capable lines. Quite often I have seen issues that the telco can't see because everything is "working". Sprint's pic seems to work best. If you can do calls @ inband (56k) multiples, it may be that you're being forced over a T-1, not the best scenario. PM if you need a tech out there.

damen
04-01-2005, 11:06 AM
Ok well, for kicks we tried a secure call, which goes through ALL the same gear except it also goes through a crypto device... and wouldnt ya know it, it works. Makes us think the issue is with timing, since crypto devices tend to fix that. We're checking it out. Just wanted to post it as an FYI for anyone else having this problem... something to check out at the very least.