Warning: Two days ago I had never touched an Adtran Atlas in my life. I crash-coursed myself on it for the sake of a project and found it so unintuitive (and undocumented online) that I felt the need to write the docs myself. But I'm the opposite of an expert, and this document may be full of hilarious mistakes. It's just that it beats nothing, which is what's currently available online. If you are an expert, please feel free to submit corrections.
The Adtran Atlas 550 is a very useful gadget for telephony nerds. If you have things that plug into phone jacks (analog, T1, PRI, BRI, several other flavors) you could probably use one. Basically, it's a big "router" for phone calls. You put up to four cards in it with different (or the same!) interfaces, then it'll deliver calls between the cards all day long.
You can use this for a lot of things - it can be an "analog to PRI converter", or a "PRI to PRI that speaks a different protocol converter", or simply a way to get eight analog phones to ring each other. It is not a PBX, even if it very vaguely resembles one, but it's a great way to connect two PBXes together.
The prices on ebay are all over the place; I suspect sellers have no idea what they have. Make sure, if you order one on there, that you get it with the cards you want or that you order the cards you need immediately before they disappear. Also be aware that there are many other Atlases, which all seem to do basically the same thing but in different, incompatible ways; the 750 and 890, for instance, are similar in function but use totally different cards.
Also, everything in this document will be about the... second gen, I think? The one without the blue panel on the front. I don't know how that one differs.
If you're not here for a tutorial, here's some useful tips. The tutorial is further down.< /p>
You will probably need to access the box over serial at some point to get it set up. Once you do this once you should never need to do it again, so it's unfortunate that it does not use a standard cable, at least on the generation I have.
The gen 3 (the one with the blue faceplate) seems to have a normal DE9 serial port. I don't know the pinout, but I can tell you that Adtran has an irritating practice of requiring null modem adapters for their DE9 ports, so have one of those on hand.
On the Gen 2, the serial port is called CRAFT (common on telco gear) and uses an RJ45 jack. Pinout is completely custom as far as I can tell. It does NOT work with a "Cisco cable" (the blue ones) nor is it a simple 1:1 match to standard 9-pin serial, so you're going to have to either order one of those DE9-RJ45 adapters with the switchable pins, or butcher a cable and twist some wires together. Here's the pinout from the manual:
RJ45 pins: 1 GND Ground - connected to unit chassis 2 RTS Request to send - flow control 3 RXDATA Data received by the ATLAS 550 4 DTR Data terminal ready 5 TXDATA Data transmitted by the ATLAS 550 6 CD Carrier detect 7 UNUSED — 8 CTS Clear to send - flow control
This same pinout is used on the 890, but with everything N/C other than TX/RX, per the manual. If you can't spare the energy to do the whole thing (can't blame you) try just doing the TX and RX; it'll be hard to do an XMODEM transfer reliably and you might get doubled inputs, but it'll be useable enough to get the Ethernet set up and then forget about it forever.
For what it's worth, I had various DE9-RJ45 adapters laying around and I was able to get it to work with one of them in conjunction with a null modem adapter. This doesn't mean anything, it's just pure random chance, but it doesn't hurt to try if you have anything on hand already.
By the way, if you're new to serial: Install Tera Term (not PuTTY; it won't get the formatting and colors right), select your serial interface, leave the settings on default, hit OK. You won't get anything in the window; press enter. That'll tell it you're there, and a login prompt should pop up. If you were already logged in, you'll get the menu.
The default IP is 10.0.0.1. Your device probably does not have this set because there's no reason it would be left at default, but you can try it.
IP settings do NOT get blanked when you perform a factory reset through the menu system. This means you can safely factory over telnet, which is great, but also means that if you get in over serial and wipe the settings, you're gonna get a rude surprise when you try to telnet in to the default IP. You have to adjust the IP info manually no matter what. I suspect there are other things it doesn't wipe, but I don't know for sure.
The "ACO" button on front is "Alarm Cut Off," and disables the alarm relay that you don't have hooked up. However, it's also the way to break into a bootloader on startup; connect a serial cable, hold ACO while you power on, and you'll get options for firmware recovery and config wipe. I suspect this wipe option goes deeper than the UI factory option and actually kills everything, but I haven't tested it.
This is a complicated question. What I said at the top of the page is "the Atlas is a box that converts between a ton of different telephone signal formats, and you want one around if you do telephone stuff for fun." But if I'm honest, I feel like I'm not quite getting what it was meant to do.
If you're using an Adtran Total Access 9xx, or a Cisco ISR, it's not too hard to figure out what they are, insofar as they're everything at once: an IP router and a phone router and a minimal PBX all in one. If you want to plug a handful of analog phones in, plus a PRI PBX and VoIP trunk, go hog, they'll make everything gel, and they even offer a bunch of PBX features on their own. The Atlas is vaguer. Adtran's own docs don't entirely answer the question "what is this for," and the manual is pretty light on actual use cases. It just kinda goes "yes, this is useful for your needs," assuming you already talked to a Solutions Expert to find out if that is actually true.
It seems to be a sort of mini phone switch, a clearinghouse that freely converts calls (and data connections) between various formats. I can tell you that it is possible to plug a bunch of analog phones into it and call between them; and to call from those analog phones to analog trunks; and to receive calls from the trunks; and to call from an analog phone to a T1/PRI trunk; and call between T1/PRI; and even to call to/from ISDN BRI. I've done all these things and they work great, so it seems like it's what I said, just a general-purpose, universal converter.
At the same time though, I get the inkling that this thing is for a somewhat more specific purpose. In particular, it doesn't do any number translation, and that bugs me. You can set an area code at the system level, and that's weird in itself because that should not be a system-level setting, but I also haven't figured out what it does with that info. It certainly doesn't use it to transform numbers, and here's what that means:
When configuring this thing, you'll be expected to define dialplans for every number that can be dialed through it, so, maybe you set up a line with the number "2065551010" - now you can go to any other device connected to the system and call that number, and it'll go through.
But call "12065551010," and it fails. Or call "5551010," from a phone that's also in the 206 area code, and it also fails. Now I don't know about you, but I'd expect it to strip off the 1 when checking against the dialplan, and I'd expect it to substitute the area code when dialing 7 digits, but it seems to support neither of these. The Total Access and Cisco ISR absolutely do, but the Atlas does not seem to be capable of it. There are a lot of other options related to modifying numbers, but they only seem to be for dealing with network switching quirks, or blunt things like removing the 9 from a call if the user had to dial it to "get an outside line." This all baffles me; how are you supposed to use it if it can't handle 7-digit dialing?
I think what's going on here is that the Atlas is not meant to ever be touched directly by a user. Yes, you *can* plug a Plain Old Phone into it, but I don't think you're supposed to; I think the only things that are ever supposed to be connected to this machine are other automated devices like PBXes, which can modify the dialed number before passing it on. Probably the only reason it has an FXS card option at all is to support old PBXes that can only handle analog lines, and devices like fire alarm dialers or elevator phones that can be programmed to dial a number exactly as specified.
I feel like I've found other quirks that I'm forgetting, but... that's a pretty big one, imo? So I guess just keep it in mind: The Atlas, while useful, is kind of an odd thing.
Okay, so you're meeting an Atlas for the first time. It's pretty unusual as this sort of gear goes - if you're used to a Cisco, or even an Adtran Total Access 9xx, you'll be lost for a while, but once the logic becomes clear, you'll find it's a decently fast and intuitive system.
I'll assume the box is sitting in front of you and you have no idea how to get into it. The first thing to do is to try plugging an ethernet cable into it (there's just one Ethernet port, clearly labeled, lower right) and see if you can telnet to it at 10.0.0.1. Use Tera Term, not PuTTY. You'll need to have a 10.0.0.x / 255.255.255.0 address of course. If you get a login prompt, you're golden; if not, you'll need to get in via serial, which is not convenient (see "Serial / CRAFT Port" section.) Once you get a login prompt, the default password is "admin". There's no username. As soon as you log in you'll be dropped into the menu interface.
The interface should be fairly self explanatory. Arrow up and down to choose a section, press enter or right to descend into the menu. If you're in a list view, the left column will often be yellow; that means you can select it to see a submenu. The same is true if you see a set of brackets around a value, selecting it will descend to a submenu with more options.
A really important thing you need to know: Setting changes do not take effect while you're in a menu. You have to back out of a section before anything you did there is applied, by just hitting left arrow or Escape repeatedly. You better believe I've gotten got by this and wasted a lot of time because I forgot to apply changes I'd made.
The first thing you'll want to do is to factory reset the device. Head over to System Utilities > Factory Default System and smash it. This will rip out any existing telephony settings, preventing Complicated Problems.
Next, set an IP address. Head over to System Config > Ethernet Port and do what you need to do. If you were serial'd in, you can now switch to telnet, it's much faster; I still recommend using Tera Term though.
Once you've done that, I recommend setting up syslog - while the Atlas has a nice (compared to some devices) local log viewer under System Status > Event Log, it's hard to read. If you go over to System Config > Syslog Setup and enter your PC's IP in the Host IP Address field, any logged events will be sent to your PC. You can pick them up in Wireshark (enter 'syslog' in the filter) or use a variety of simple utilities, such as Visual Syslog. Trust me, you will be glad you set this up. By default very little will be logged, so you should also head to System Config > Event Logging and set Switchboard to Info. That will log an event any time a phone call is attempted; obviously quite useful. More categories will become relevant later.
The next thing you'll want to do is check your modules. I assume your machine came with some cards in it; if it didn't, it won't be very useful. I can't promise this, but I believe that all the cards perform basic functionality without any special licenses, so you should be able to buy them on eBay with no worries. There's a license section but I don't think it was ever used (at least one manual says it wasn't.) Assuming you have cards though, you'll want to go to the Modules menu to see what's present - but don't take off running! This section does NOT do what you think it does, so keep reading.
If you're like me, you assume this is where you Get Started by turning up some T1 or FXS ports so you can start plugging stuff in and getting links up. It isn't! This is primarily for monitoring status (it's where you check your T1/PRI channel utilization, see whether an FXS port is onhook or not, etc) and applying some very low level options (like FXS port impedance) but nothing you do in here will make a port start emitting a signal. Just make sure everything you expect to be here is here; if not, shut down and reseat any missing cards, then try again. Once everything is present, we can proceed to making dialplans.
The Atlas uses a very strange approach where ports are enabled automatically when added to a dialplan, so that's what you need to do to get started. As soon as you have a dialplan entry targeting a given port, that'll bring up layer 1 (whether that means a T1 going green, or an FXS getting dialtone) so you can confirm the device is actually talking to the Atlas. Once that's done you can work on actually making it behave properly, so you'll want to build dialplans as your first step. To do this, head over to the Dial Plan menu.
First we just want to get the port up, so we'll put in a skeleton config.
The first thing you want to do is go to Global Param and set an area code. It defaults to 000 and will fill this in randomly on ISDN calls, it's irritating; put something in there. Next, you'll need to pick User Term or Network Term depending on what you're connecting. Here's the rubric:
Why does this distinction exist? Phone reasons. Don't worry about it. No but really, there are a lot of implications to this decision, and one example is that if you're configuring a PRI interface, putting it in Network Term will cause it to assume the Network end of the dialog. Most PBXes operate in User mode, so this will work, but certain devices (such as the Livingston/Lucent Portmaster) operate in Network mode and will not sync. If this happens, you have to rip the port out of Network Term in the Atlas and rebuild it in User Term, at which point it'll change functional roles automatically.
The best bet for starting out is to follow the rubric: Put end-user devices in User Term, everything else in Network.
Once you've picked a section, you'll find it empty by default. If it isn't, I recommend you go back and factory reset the device before continuing. Once you do that, arrow over to the list and hit enter to create your first entry. Hot Tip: To make additional entries just hit the letter I, and to delete entries hit D.
The first field is the Slot - if you're lighting up a PRI port, pick your PRI card, for FXS pick your FXS card, etc. Then arrow to the Port/PEP field and pick a port within that device. This is enough to bring up the port - arrow/Escape out of the menu (make sure you hit it enough times to leave the screen entirely) and plug into whatever port you just enabled, and you should find tone/sync.
On an FXS port, this should Just Work. If it doesn't, uh... check your cabling? But I'll assume you got dialtone; proceed to the next section if so.
On a PRI (look, I know you aren't using a raw CAS T1) you might fail to get sync at either layer 1 or layer 2. If you aren't sure which one is failing, you can head over to Modules to find out.
Select your T1 card, then T1/PRI Menus, then Signal Status. If you see a line of 1's, your T1 is up; if you see Port Not Active, your T1 is down. Head over to Alarm Status. If you see LOS[*] and RED[*], it ain't plugged in. Build a T1 crossover cable and try that. If that doesn't work, or if you see RED[*] but no LOS[*], you have a signal mismatch. Go back up to the module menu, then go to Configuration and pick the relevant port, and you'll get the line code/framing settings, which are usually the only thing you need to change. You can also name the port there if you want, so you can pick "Cisco" from lists instead of "T1/PRI 1."
If the T1 is up but your other device is still mad, you need to look at the PRI status. Go to DS0 Status. If your port is a series of dashes followed by D, it's up and running; if you're still having trouble, you might need to change switch types. If it's an O followed by a series of dashes, you have the wrong protocol selected (RBS instead of PRI) in the dialplan. If it's a dot followed by dashes, you're failing to bring up the D channel for some reason. In all cases you want to go look at the protocol mode and interface config in the dialplan and... see if anything looks out of place? Compare to the settings on the device you're connecting to and make sure they match.
If you've checked everything with no joy, you might have a Network/User mismatch. Try rebuilding the port under User Term or vice versa.
If you're doing ISDN BRI (congratulations!) you'll have selected a BRI card and port, and the diagnostics for same can be found in the module settings, but there's a lot les to it. All BRIs are identical as far as I know so there's no layer-1 config. The Channel Status will show a D if the D channel is up; if not, you have a layer 1 problem. Either you have bad wiring going to your device, or your device does not have a U port like you thought and requires an NT1 to convert the U to an S before it can be connected. NT1s have no intelligence, so if you get one and plug it in it should sync the port and a D will appear.
Anyway, let's assume you got your port up and running.
A couple notes before we proceed:
A port doesn't need a meaningful dialplan to dial out. As long as it's up, the Atlas will allow calls to other ports, it just won't be able to receive any. Of course, this is moot at first because, out of the box, none of your ports will have dialplans, so you need to define something before you can proceed.
Also, if you're working with ISDN BRIs, those require a SPID entry in the dialplan before they can function at all, which I'll detail later. But you... probably aren't doing that.
Select one of the ports you've configured from either User Term or Network Term. You'll see a new menu, with two options: Accept List, which determines which calls will be passed on to the port you've selected, and Reject List, which defines numbers that can't be dialed from this port. You'll be spending most of your time dealing with the Accept.
In simple terms: When the Atlas receives a call, it looks at the destination number, then walks through all the ports in your machine looking for one that has that number in it's Accept list. You can put single numbers in the list, or number ranges; the list is then processed in order of specificity, so more specific rules override less specific ones. I'll show you what I mean as we go.
One comment first however: the Accept field on Network Term says "Outgoing Number Accept List," while the one on User Term says "Incoming Number Accept List." This is confusing, because they actually do the same thing - it's just that from the perspective of a User, a call going towards them is "incoming", but if the call is going to a Network device, the perspective is that of the Adtran, so the call is "outgoing." Seriously. An Adtran employee said this! So ignore what it says, and just remember that any number that lives on this port has to be in the Accept list.
This is slightly different depending on whether you're working with a T1/PRI, an FXS/FXO, or a BRI. I'll explain the PRI process first, then the differences for the other two.
Go in and select your desired port in Dial Plan, then go to Incoming Number Accept List. Arrow over and hit enter to make an entry. Edit the Accept Number field.
You can just punch in a single phone number here if you want: Put in "5558080", and now calls to that number will hit your PRI. But if you edit the field, then hit Ctrl+A, you'll see that it's actually a pattern, which can match many numbers.
Suppose you want to route any call going to 555-3000 through 555-3500 to the PRI: you would populate "555-3[0,1,2,3,4]XX". The X means "any single digit"; the hyphen is optional, it's just for readability. This will match everything from 3000 to 499.
For that last number, -3500, you'll have to add one more entry. Go back to the Accept List, press I to add another entry, and put in "555-3500". Just like that, with two rules you've routed 500 numbers - slick, right?
Okay, now suppose someone comes by and says "Hey, I need you to pull out 555-3431 and route it to this gate call box that I'm plugging in to FXS port 4." That's easy; you don't actually need to change what you entered at all, because of that "specificity" thing I mentioned earlier. If you simply add an Accept rule to your FXS port (as I'll explain lower down) with that number, it'll override the PRI, because it's more specific: "555-3431" describes only one number instead of 500, so it wins.
The same applies if you were asked to punch out, say, numbers -3420 to -3430 and run them over a second PRI. You would go back to the list, select that PRI, go to it's Accept List, then add a rule with the pattern "555-34[2]X" to cover -3420 to -3429, and a second rule with just "555-3430" to catch the last one.
And... that's pretty much it! At this point you should be able to make calls go to your PRI.
Oh, one last note: There is a built-in priority system. If you assign the EXACT same number to two lists, whichever one has the lower slot/port number will win, if I understand correctly. This is useful if you want to have two identically-configured ports, with one acting as a backup; if the lower-numbered one loses sync, the remaining one will accept the calls in its stead. This is hardcoded though, so if it's a problem (for some reason) I think you can swap the cards physically, or swap your devices so the higher priority one is on a lower-numbered port.
For the most part, it's the same as the PRI process, so follow that. The difference comes in how you assign ports.
For the simplest config: Add a new dialplan entry under User Term. Select your FXS/FXO card, then pick Port 1. Go to the Accept List and put in a single number. Now when you call that number, the port will ring. Terrific. For a wrinkle: Add multiple numbers, or a range, and all of them will ring to that single port. Also terrific.
But now, go over and take a look at the Interface Configuration page. By default, an analog dialplan assigns a single port - represented in the "Ports Available" list by an exclamation in place of the port ID. But if you increase teh Number of Ports field to 2, you'll see two exclamations; now, if you call the number you assigned, it'll ring to the first port, but if that's busy, it'll then ring over to the second one. You can expand this up to all the ports on the card.
Set your Ports Assigned to 2, then leave the page. Make a new dialplan entry, pick the same card, but a later port (let's say 6, assuming you're on an 8-FXS card.) When you look at the Interface config, it'll look like this:
Notice the two s'es. Those represent ports that are already in use by some other line; you can't overlap them. If you were to now go back and set the first dialplan to 6 ports, that would try to seize port 6 that you've already assigned here, and you'd get an error.
There are probably some other nuances, but these are the ones I've noticed so far.
Oh boy. BRI.
If you're messing with BRI, welcome to the brotherhood (etc) of People Who Waste Their Time On Dead Futures. You're in good company. I assume, by now, that you know the basics: BRI is a digital phone line that offers two concurrent calls over a single wire pair, or two digital data channels, or any combination thereof. It does so by using the same ISDN signaling that PRI uses, but with only two voice paths (or "B channels") plus a control path (or "D channel".)
As noted earlier, it's extremely easy to get BRI connected: If your device has a "U" port, you just plug it in to the BRI card. If it has an "S", "T", or "S/T" port, you have to plug it in through an NT1. Note that the NT1 itself will make the port on the Atlas link up; it's up to the lights on the NT1, or your endpoint device (phone, etc.) to tell you if the S/T side came up. Beyond this however, actually configuring the dialplan on the Atlas is... weird. For reasons I don't really understand.
First, you need to configure a SPID, an arbitrary number used to identify a device to the BRI switch and tell it which capabilities it has. Imagine that you have both a phone and a modem plugged into the same BRI port (a not-uncommon occurrence.) They might be sharing a phone number, but the Atlas needs to know that one of them can only accept voice calls, while the other can only accept data calls. By creating two SPIDs, the devices can tell the switch which one's which. Even if you're just setting up a single phone however, you need at least one SPID.
Enter the list, create an entry. Put whatever number you like in the SPID field; it literally does not matter, feel free to use the phone number, I do. Then you need to put the actual phone number in the Phone # field, and this is where things get weird.
This field is limited to 7 digits. I have no idea why. It's the only field in the entire system that is, and this is not a limitation of ISDN. Real ISDN phones, and real ISDN switches, did not have this requirement. If I understand Adtran Support correctly, even if you build an Incoming Accept List entry for, say, "2065551010", the BRI card will only look at the first seven digits: "2065551." This is hopelessly broken, because there seems to be no way to get the Atlas to trim off the area code. It appears to simply be impossible to dial a BRI user by 10 or 11 digits. I'd love to find out that I'm missing something here; email me if you know a solution.
Anyway, now that you know that, you know what you need to: Add the 7-digit number to the inbound accept plan, save and call it, and it should go through.
I'm incredibly tired after writing all this. Maybe I'll add info on troubleshooting in the future; for now, just be aware that if you set up syslog, you'll get a lot out of setting "Switchboard" and "ISDN Events" to "Info". Most of the problems you'll run into after this point will be explained in plain text by those logs. If you see something along the lines of "No unbusy line accepted call to number [xxxxxxxxx]", that usually means your inbound accept rules aren't right. Good luck sailor