Cannot receive incoming calls on 890 but can on 550

[kmarie]

I rarely work with the 890 so please forgive me.

I have two PRIs that are broken out into BRIs for videoconferencing. When my PRIs are plugged into my 890 I cannot receive incoming calls, get a busy signal. We can connect outgoing calls at 384k. When we plug the same 2 PRIs into our 550 we can make and receive 384k calls. I've checked and compared the settings and I haven't found any differences. Maybe I'm missing something. Is it possible to have a bad network card in the 890 that would cause this problem on all 4 ports? I would appreciate any help. Thank you in advance.

[Anonymous · Accepted solution]

Hello, and thank you for using the ADTRAN Support Forums.

When doing PRI to BRI through an ATLAS, and you can dial out, but cannot receive inbound calls - the first thing that comes to my mind is the SPID configuration on the BRIs under the DIAL PLAN. If the SPIDs do not register outbound calls will work, but inbound calls will not. The SPIDs are configured under the DIAL PLAN, USER TERM, IFCE CONFIG, in the SPID LIST. Under the SPID LIST there is the PHONE NUMBER as well as the SPID. The PHONE NUMBER in here should match the IN#ACCEPT, up to 7 digits. Under the SPID LIST, the PHONE NUMBER should never be more than a 7-digit number (so no area code).

If that looks correct, I suggest going under the SYSTEM CONFIG into the EVENT LOGGING, and set the SWITCHBOARD, and ISDN EVENTS both to INFO. Once that is set, back out to the main menu, go to SYSTEM STATUS and view the events in the EVENT LOG (you can clear the events by hitting <Enter> on CLEAR SYSTEM EVENT LOG, under SYSTEM STATUS). When you receive an inbound call, you should see something like "Call to ATLAS" and when it works it will have "Dialing 5551212" (or whatever number is coming in). If the call doesn't go through there should hopefully be events to explain why the call did not go through. You can respond in this thread with any events that are displayed if you need help understanding them.

Thank you,

Patrick

[kmarie]

Patrick, thanks that fixed the problem. Now I have to prove to the telco company my 890 is not causing corrupted data error during video conferencing.

We have two independant PRIs each with a block of 40 numbers. When I unplug PRI#1 I get a corrupted data error on PRI #2. I've plugged PRI #1 into the media converter supporting PRI #2 and I still get the corrupted data. If I unplug PR#2 and make a VTC call on PRI #1 I do not get corrupted data. I've also plugged PRI#2 into our 550 and I still get corrupted data. The telco company swears nothing is wrong but I'm wondering if it's the media converter if I'm not missing a setting in the 890. I have both PRIs programmed the same in the 890.

On a separate note, can you explain bandwidth allocation. I thought that if I had to independant PRIs that had their own block of numbers that if I made a call from a system assigned with a PRI#2 number it would connect on Port 2 but it connects on Port 1 and when I receive a call on that number it connects on port 2. So from current setup all my VTC sessions will connect on Port 1 (PRI#1) because there are all outgoing and they will not connect PRI # 2 until PRI #1 is full. So if PRI #1 goes down I will lose all of my connections. Any explaination would be great.

[Anonymous]

With the corrupted data, you can look and see if the ATLAS is showing any errors on the T1 interface. You can look under MODULES and go into the MENU for the specific T1 module you want to look at, and look at PERFORMANCE CURR (there is also 15Min and 24Hr displays). Everything listed under PERFORMANCE is a type of error that can be detected. If you move your cursor to a port number and hit <Enter> it will change the view so you can read what each type of error is (ES is Errored Seconds, etc.). If a T1 port does not have a circuit plugged into it, then it will count errors - this is normal. The CSS error is Controlled Slip Seconds, which is also known as clock slips or timing slips. If you are seeing those on one of the PRIs then it is a timing issue. The ATLAS only supports one clock, and all the interfaces on the ATLAS are then timed off that one clock. If the two PRIs are from different central offices, and are not using the same clock source then you are going to see clock slips. (The ATLAS' timing source is configured under SYSTEM CONFIG.)

For the bandwidth allocation, the ATLAS primarily routes based on the phone number dialed. So the two PRIs are under the DIAL PLAN in the NETWORK TERM, and more than likely each has an OUT#ACCEPT of "$". This means they will accept any number dialed, and the outbound call will use the first available PRI.
Inbound calls are routed to the USER TERM entries based on the IN#ACCEPT list for each interface. Since you've already defined which PRI each number should come in on, the inbound calls should not be an issue.

In order to configure specific USER interfaces to go out a specific NETWORK PRI, I suggest using SOURCE IDs. If you go into the NETWORK TERM OUT#ACCEPT list, you will see there is a Src ID column, which defaults to a value of "0" (then an ACCEPT NUMBER of "$" and a SEARCH of "PRIMARY"). If you then look under the IFCE CONFIG of all your USER TERM entries, you will see they are all configured with SOURCE ID of "0" (this is the default). So you can configure your second PRI with an OUT#ACCEPT list using SID=1, ACCEPT NUMBER of "$", and SEARCH of "Primary"; then create a second OUT#ACCEPT for Src ID of "0", and ACCEPT NUMBER of "$", and a SEARCH of "Secondary". On your first PRI you should add an entry for Src ID of "1" with a SEARCH of "Secondary." You will then want to go into the USER TERM on the entries you want using the second PRI, configure the IFCE CONFIG so that they have a SOURCE ID of "1".
The NET TERM search of PRIMARY and SECONDARY will allow calls to go out the "other" PRI if the primary PRI is down.

So as a quick review, you are assigning certain USER TERM entries with a SOURCE ID of "1" (under the IFCE CONFIG) in order to route them out the second PRI, and then you configure the NETWORK TERM PRIs to accept either Src ID of "1" or "0" as the PRIMARY search, and then "0" or "1" as the SECONDARY search item.

Hope this makes sense.