Connect one input T-1 with another input T-1

[crennie]

I have two T-1's in a Atlas 830.

1) is from a PBX

2) is from a Redcom Slice 2100

http://redcom.wpengine.com/products/commercial/slice-2100/

The Slice has two endpoint extensions on it, with the Redcom connected directly to the PBX I am able to make both inbound and outbound calls.

I would like to put the Atlas 830 in series with the PBX and the Redcom, I would like to make calls between the two units using the Atlas 830

The question is how do I come in on one T-1 and get out on the other in both directions.

[Anonymous]

The ATLAS routes calls through the DIAL PLAN based on the number dialed. The IN#ACCEPT and OUT#ACCEPT (depending on if it is NETWORK TERM or USER TERM) lists are how the call is routed.

The ATLAS dial plan is labeled based on what the ATLAS is terminating to, so NETWORK TERM terminates to a "network" and the ATLAS is therefore in a "user" role. USER TERM terminates to "user equipment" and the ATLAS is therefore in a "network" role.

In your diagram you can have the T1 to the Redcom configured with an IN#ACCEPT (or OUT#ACCEPT) of 557-3505 and 557-3502, while the T1 to the PBX has an IN#ACCEPT of 637-3920, or you can use the wildcard of "$" which means to accept anything. The ATLAS will route the call based on the most specific match, so if you use specific numbers for the T1 to the Redcom, and "$" for the T1 to the PBX, then anything dialed that does not match the Redcom numbers will be routed to the PBX.

Hope this helps,

Patrick

[crennie]

I have review the Atlas unit and the attached is the screen shots from it

Network Term = In#Accept as ($) for PBX

User Term = In#Accept as (3XXX) for both

In this configure I get a busy signal both ways

Changed the 3XXX for $

In this configure l get dead air, no busy or ring

[Anonymous]

I suggest you do some logging in the ATLAS to see what is happening with the call. You should also verify the D-channel is up on the 2 PRIs you are wanting to route the call to.

Under SYSTEM CONFIG go into EVENT LOGGING and set both SWITCHBOARD and ISDN EVENTS to INFO. You can then view the events under SYSTEM STATUS in the EVENT LOG.

With your IN#ACCEPT set to "3XXX" if the number sent to the ATLAS is different (such as "555-3XXX") then that is not a match. Also, if the D-channels are not up the call will fail as well.

If you get the message "Call Failed after Switchboard" then the ATLAS routed the call and it was rejected by the end equipment.

[crennie]

I know that the Redcom can except four digits. Had calls from the PBX to the Redcom direct and it except them 3502 and 3503.

Log below was from a call thru the PBX to the Atlas to the Redcom ext 3502

[Anonymous]

From the screen-shot, the call is routed out Slot 1 Port 3 (S1.3) at 11:56:33 and then it looks like the ATLAS receives a "disconnect" at 11:56:41 on S1.3.

The call then comes in S2.1 at 12:07:55 and goes out S1.3 immediately at 12:07:55 (after the switchboard determines it cannot route it back out S2.1 - '33502' rejected - Primary busy) and then the calls it disconnected at 12:08:03.

The call is definitely coming into the ATLAS as only the 4-digit extension (Call to ATLAS: '3502') so your IN#ACCEPT of 3XXX should work correctly.

To get more detailed information you will need to set ISDN L2 FORMATTED events to INFO. This will give you a LOT of information and if you want to share it on this forum you'll need to save it to a SYSLOG server (because piecing together multiple screen-shots for each stage of the call is difficult).

[crennie]

How can I get the complete log file for this test, I'm am seeing a lot of new data information. I would lie to get the text file for you

[Anonymous]

To save the EVENT LOG to a file you will need a Syslog Server program. (Kiwi has a free Syslog server at the bottom of this page - <Free Download | Syslog Server, CatTools, Syslog Viewer | Kiwi Syslog> or you can use the TFTP server option in Jounin's TFTP daemon found here <TFTP server>.

This document covers using the ATLAS with the ADTRAN Utilities Syslog server, but the ATLAS configuration is the same no matter what server you use.(Using the Adtran Utility Syslog with the Atlas The ADTRAN Utilities were written for Windows 95, so I don't suggest you use that. I have used both Kiwi and TFTPD32 and they both work well. If you have another Syslog server program that should work as well, since it is a standardized protocol.

In the screen-shot above, the RESTART messages are a maintenance feature that can be disabled. If the ATLAS sends a RESTART INDICATOR and there is no response, then the channel will be taken out of service. If there is a response (RESTART ACK) then that indicates the channel is in service and available. If you want to disable the B-channel Restarts, you do that under the DIAL PLAN, in the USER TERM, under the IFCE CONFIG.

[crennie]

I have two for you based on your logging request.

How do I send test logs to you?

[crennie]

Also question on the firmware version

Adtran ATLAS 830/System Info

System Info   x System Name                        Adtran ATLAS 830

System Status x System Location               St John

System Config x System Contact           Adtran ATLAS 830

System Utilityx Firmware Revision        A.02.04 11/24/03 08:35:32

Modules       x System Uptime            0 days  10 hours  42 min  53 secs

Packet Managerx Startup Mode             Warm reboot

Router        x Current Time/Date (24h)  Tuesday September 30  18:40:23  2014

Dedicated Mapsx Installed Memory         Flash:8388608 bytes  DRAM:16777216 byte

Circuit Statusx Serial Number            D42F8337

Dial Plan     x Boot ROM Rev             A.01 07/29/02

[Anonymous]

The most recent FW for the ATLAS 830 is A.04 so I do recommend upgrading as soon as you get a chance.

[Anonymous]

I'm sorry. I thought you could attach a file, but I don't see that option available. I'm afraid you'll have to either upload the files somewhere accessible on the internet and post a link to them, or copy and paste as much as you can.

Actually, you may not have this option, but there may be an option in the upper right-hand corner of your reply box that says "Use advanced editor". If you do have that option, once you click on it, there is an "attach" link in the bottom right-hand corner that will allow you to attach a file - however this option may only be available to administrators.

[crennie]

i have calls getting from the the PBX Mod 2/1 to the Redcom Mod 1/3

1) Endpoint (557-3502) rings

2) Calling number 8137040083 get disconnected (Re-order)

3) Endpoint continues to ring, I can answer it but the calling number has been dropped.

The attached log is still based on your setting request.

I can not dial out from the Redcom Endpoint yet.I know that the Redcom is working I had it connected directly to the same PBX that the Adtran is using now.

[Anonymous]

Thank you for the log files. That is exactly what I was looking for, but it actually raises more questions.

The log starts off at 18:01:14 and the ATLAS receives a call (SETUP) on S2.1 from 670XXX1205 to 3502.

For this call the ATLAS sees there are no available channels on S3.1 so the call is refused as "Busy"

There is another call at 18:01:24 and the ATLAS still does not show any available channels on S3.1 so the call is refused as "Busy"

Then at 18:29:48 the ATLAS receives another call on S2.1 from the same number

The ATLAS sends a CALL PROC(eeding) to acknowledge the SETUP and let the PBX know it is trying to route the call.

The ATLAS then sends a SETUP message out S3.1

There is no response from Redcom off S3.1 so the ATLAS sends another SETUP at 18:29:52

There is still no response by 18:29:56 and the ISDN timer expires, so the call is torn down with a DISCONNECT

This same process takes place at 18:30:29, again with the ATLAS not receiving any response on S3.1

The rest of the night, the ATLAS sends RESTART messages every hour for all 23 channels on S3.1 and never receives any response back.

Through this whole log the ATLAS never receives any messages on S3.1. Is the Redcom possibly configured for NFAS and sending messages out another T1 interface?

Technically the ATLAS should never send a call to the Redcom on S3.1 because the RESTART messages were never acknowledged. So to start with I believe the B-Channel restarts need to be disabled on that PRI.

If the Redcom IS configured for NFAS then the ATLAS needs to be as well, and the Primary D-channel needs to connect to the ATLAS (you can't split NFAS PRIs between devices because it uses a shared D-channel for all the T1 interfaces).

As I mentioned, the key that I see in this log file is that the ATLAS never receives any D-channel messages on S3.1

[crennie]

Two screen shots of the T-1 setups

I had the Slice working directly with the PBX before connecting it to the Adtran

[Anonymous]

I'm sorry. My previous notation was incorrect. It is S1.3 and not S3.1 as I wrote earlier.

I understand that the ATLAS is not configured for NFAS, but that doesn't indicate if the Redcom is or not. For the D-Channel to become active, the ATLAS transmits a SABME message and receives a UA response back. Once that happens, the D-channel is active.

In the log you sent in there are no messages received by the ATLAS on S1.3. The D-channel is already established so those messages are not in the log. The ATLAS sends RESTART messages and even sends SETUP messages but never receives any response to them, and there are no messages originated by the end equipment off S1.3

The fact that you say the end phone does ring indicates the SETUP message is received and processed by the end equipment but the ATLAS never receives any D-channel messages to acknowledge the SETUP or indicate the call is being processed.

You can try moving it to another T1/PRI port on the ATLAS, but the fact that the D-channel does get established indicates there is communication. If the end equipment is configured for NFAS, then the CALL_PROC and all other acknowledgments may be sent out the PRIMARY D-channel to some other equipment.

[crennie]

OK got a inbound call to the endpoints on the Redcom.

To be honest with you it was the Primary clocking Mod and Port.

We had it on Slot:1 Port:1 T1/PRI

They moved the PBX T1 from that location but they never up dated the "Primary Timing Source"

Thanks for all your help, I am better off now with this system. Have one more problem that is outgoing call from the Redcom thru the Adtran to the PBX (test dialing is 9 and for digits)