Adtran Atlas 550 - New to Adtran - May be a dumb question

[voip123]

New to Adtran.  Have an Atlas 550. 1-T1 Network Interface in Network Slot1, 1-Dual T1/PRI module in Slot1, 3-Octal FXS modules in Slots2,3,4.   I am only using this unit to convert the PRI to analog extensions.  I have 23 analog lines being used.  I have one incoming PRI.  Which port do I plug the incoming PRI into?  Do I bring it into the network slot and then put a cross-over between the 2 T1 ports on the Dual T1/PRI card? Or do I come directly into the Dual T1 card Port 1 and leave Port 2 empty?  Or is the Network port for a pbx to connect?  My user terms are set up to the 2 Dual Ports.  My Network Term is setup to the Network Port.

[jayh]

Plug the PRI into one of the ports on the dual T1/PRI card. PRI is ISDN delivered over T1, so a PRI is T1, with ISDN signaling.

Depending on how the PRI is delivered you may need a T1 crossover cable. This is different from an Ethernet crossover. Pins 1 and 2 are swapped with pins 5 and 4. (blue-blue/white swaps with green-green/white on 568A or blue-blue/white swaps with orange-orange/white on 568B). If the T1 comes up you don't need the crossover.

[voip123]

Tried port 1 of Dual T1 card and no luck.  Seems like it should be the

network port.  I can get the T1 card light to clear and the adtran network

light to clear with a straight through cable.  Still no calls in or out

with either method.

Thank you,

Jesse

[jayh]

OK, you've got layer 1 up. Now you need to configure the PRI part. Typical things you'll need to set are User vs. Network role, switch type, etc.

[Anonymous]

Jesse,

How, and where are the FXS ports configured? You said you have 2 ports of the Dual T1/PRI module configured under the USER TERM. From what you described, you don't need those. You need the FXS ports configured in the USER TERM. The IN#ACCEPT is the phone number that will ring the phone off the specified FXS port, so you can either have the same IN#ACCEPT for all of them so they are in a hunt-group, or you can have each port have an individual IN#ACCEPT.

-Patrick

[voip123]

I appreciate everyone's help.  Still having some trouble.

Slot1 = Quad T1/PRI module

Slot2 = Octal FXS module

Slot3 = Octal FXS module

Slot4 = Octal FXS module

Ntwk1 = Single T1/PRI module

Ntwk2 = Empty

It looks like the DS0's point to the Slot1/Port1 T1 in User Term and then the FXS-8 modules in Slots2,3,4 point to the Slot1/Port2 T1 in Dedicated Maps.

The Network Term points to the Network1 Slot Single port T1.

However I don't see how the incoming PRI in the Network1 Slot ever gets pointed to the other devices.  If I try to point any of the DS0's to the Network1 Slot is says conflict.

I attached some screenshots in the file below.

[jayh]

In your screenshot you have the T1 interface set to RBS. This is robbed-bit signaling, not PRI. Both are used for voice, but the signaling and control is totally different.

With PRI, you don't map DS0s to FXS because the channel of a call is assigned dynamically by the D channel. You'll use a dialplan to route the calls to the FXS ports. The configuration of the ATLAS is substantially different between PRI and RBS.  Remove the mapping and change the signaling to PRI, see if you can get the D channel to come up. Once you get the PRI configuration happy you'll need to map the phone numbers to the FXS ports with a dialplan.

[voip123]

I deleted my Dial Plan and Dedicated Map.

I set it up to only use the T1 in Network Slot1.

I set up User Term and set signaling to PRI.

Then set up my Dedicated map to map the last 8 FXS ports to specific numbers.

However I need any incoming calls, that don't match the telephone numbers assigned to the last 8 FXS ports, to ring into the first 15 FXS ports in a round robin pattern.

Based on the DNIS information passed to these 15 analog lines, the alarm receivers determine what to do with them. Each analog line goes to an individual line card. 

The idea being any line card can answer any number and route it by DNIS. So even if a line card were to fail that telephone number would still work on another line card.

I can't map those 15 FXS ports to anything because it says they are in use in the Dial Plan.

I attached my new screenshots.

Thank you for your time.  It is much appreciated!

[Anonymous · Accepted solution]

I believe your original configuration was closer to being correct. The PRI should be in the NETWORK TERM because it is terminating the network PRI from the Telephone Company. The first USER TERM RBS T1 is needed for the "rabbit-hole" configuration in order to get the *ANI*DNIS* DTMF digits out pulsed from the FXS ports. The ATLAS can only out pulse *ANI*DNIS* from a RBS T1 interface configured for Feature Group D (FGD). Since your alarm receiver needs this output from an FXS port, the USER TERM T1 is connected to another T1 interface with a T1 cross-over cable, and that second T1 interface is MAPPED to the FXS ports.

The reset of your USER TERM entries look like they were using the same principle and had specific numbers in the IN#ACCEPT in order to route the calls to the FXS ports in the DED MAP. It loos like these USER TERM entries are configured for LOOP START rather than FGD, so I don't see a good reason to remove them and just configure the FXS ports in the USER TERM, using the IN#ACCEPT to route specific calls to the desired FXS ports.

As Jay mentioned, you don't map FXS ports or even a T1 to the PRI, because the channel allocation is done dynamically with the D-channel signaling. The ATLAS routes the calls based on the IN#ACCEPT lists.

So for your alarm receiver you need an RBS T1 configured for FGD, which has a T1 cross-over to another T1 interface, which is then mapped to FXS ports.

For standard phone lines, you can have the FXS ports configured, and each have individual numbers in the IN#ACCEPT, or they can have the same number in order to form a hunt-group.

[voip123]

The information for the "rabbit-hole" config is great.  I checked it against my original program and that is how it was set up.  My PRI connection comes online correctly when plugged into the network port and with a cross-over between the other 2 T1 ports the system is happy.  However I still cannot make calls or receive them.  I get this error when trying to call out: "Call clearing: INVALID_ELEM_".   I plugged the T1 connection in at 11:36 and removed it at 11:44.  I don't have the luxury of being able to leave it connected.

[Anonymous]

The INVALID_ELEM_CONTENT is on the N1 PRI. So that indicates the call may be going out but we don't have enough details to know much of anything. I suggest going under SYSTEM CONFIG and into the EVENT LOGGING, and set SWITCHBOARD and ISDN EVENTS to INFO. If you have a Syslog Server program you can have the ATLAS send the data to, you can also set ISDN L2 FORMATTED events to INFO, but that is very verbose and will fill the ATLAS' buffer very quickly. It may require ISDN L2 FORMATTED logging to figure out what is being rejected as "invalid" but we have no information yet.

Are you doing 7-digit or 10-digit local dialing? What is the number you are dialing? If you are sticking with the T1 in the USER TERM and the FXS ports in the DED MAP, then I suggest configuring the USER TERM entries with a "Caller ID Number" so the ATLAS will present a "Calling Party Number" when sending a call to the Telco.

[voip123]

I will turn on those logs and get some more information.  I'm making progress.  I now can get inbound calls and they are routed to the proper number.  My mistake was in my dialplan.  I had "$" for my incoming number accept entry for my circular group of 15 lines listed at the top of the list.  I moved it down to the bottom and also filled my other incoming numbers in with the full numbers including area code.  Just have to get outgoing working now.  I will try the caller id field.

[voip123]

I removed the area code from the In#Accept Field and it still routes correctly.  Also added caller id number to each user term.  Still can't call out.  Enabled the logs except the verbose one.  Might have to do that tomorrow to see what is going on.  I was trying to call 16053218162 from DS0=18.

[voip123]

Went and turned the 'ISDN L2 Formatted' Log on and ran another test.  I was

calling 16053218162.  Results Attached.

Thank you,

Jesse Johnson

On Mon, Oct 12, 2015 at 3:48 PM, patrick <

[voip123]

Went and turned the 'ISDN L2 Formatted' Log on and ran another test.  I was calling 16053218162.  Results Attached.

[Anonymous]

Do you have a full PRI? The "Diagnostic" for the INVALID_ELEM_CONTENT is 18, which, if I'm reading everything correctly is the channel identifier; and the ATLAS is requesting channel 23.

So you can change the number of channels on the PRI to 10 or so, and try again. If the call goes through then work your way back up toward 23 and see where it starts failing, or you can change the channel selection to CIRCULAR and place call after call (keeping track of the channel) until one goes through.

If no calls go through, then you'll have to have the service provider monitor the call and tell you why the call is failing.

Thanks,

Patrick

[voip123]

I now have incoming and outgoing working.  To get outgoing working I had to change my "Outgoing Number Conversion" from "ISDN-National As Dialed" to "ISDN-National pref".   The last piece I need to get working is DNIS.  Currently Caller ID is working but DNIS is not being passed correctly.  What log can I turn on to see what DNIS is being sent?  My receiver looks like it needs 5 digits of DNIS.

Image below of Ded Map From Connects config.  What does the Wink do and is it worth playing with the DNIS Delay settings?

[Anonymous]

The "DNIS Wink Timeout" does not interfere with transmitting the DNIS digits. If you move your curser to that option and hit Ctrl+a it will bring up a HELP window. This options sets a 5 second timer where the WINK will be transmitted on the T1 whether the FXS port is answered or not. If this is enabled the Wink could be sent and the DID digits transmitted before the FXS line is even answered.

For logging, I suggest setting DP OUTGOING SIGNALING to NORMAL in order to see the DID digits transmitted. Since you are doing FGD with ANI/DNIS the ATLAS should be transmitting *ANI*DNIS* but this will give you the exact digits being transmitted (in case it is less than 5 digits). If it is transmitting less than 5 digits then you may have to set up a DNIS SUBSTITUTION in order to add a digit to the number.

[voip123]

Disabled Dial Tone and changed DNIS Delay from 1 sec to 2 secs and it is working now.  Thank you so much for everyone's help!  I want to especially thank Patrick as his answers were extremely helpful!