Redundant PRI Configuration

[hes]

I have multiple network telco provided PRI's connections on my 550 and a third userterm PRI connected to my phone system. I have no issues routing outbound calls the two either network PRI based on the dialed number. My issue is I would like to set up the Atlas 550 with a preferred route but still allow calls to go out the non preferred Network PRI if the Preferred PRI is unavailable. For example:

Call from userterm PRI to 444-444-4444 routes to Network PRI 1. Call from userterm PRI to 555-555-5555 routes to Network PRI 2. If Net 2 is unplugged and a call is placed from userterm PRI to 555-555-5555 I would like it to go out Network PRI 1 since Net 2 is unavailable.

Is this possible?

I tried the following but it routes to the more specific number regardless if the circuit is available or not and the call just fails if the preferred route_ is unavailable.

NET1

OUT#ACCEPT $

OUT#ACCEPT 444-444-4444

NET 2

OUT#ACCEPT $

OUT#ACCEPT 555-555-5555

[Anonymous · Accepted solution]

Thank you for using the ADTRAN Support Forums.

Yes, the ATLAS OUT#ACCEPT and IN#ACCEPT routes based on the "most specific match" and does not allow a call to route to a "less specific match," but what you want is possible and you were on the right track.

If you'll notice, in the OUT#ACCEPT list there is a column labeled "SEARCH" and by default it is "Primary". You should add the "other" NET TERM's number or pattern to each of the Network PRIs and set the SEARCH to SECONDARY. A call will only be routed to a "Secondary" if the "Primary" is either full or down. So you should have something like this:

NET1

OUT#ACCEPT 444-444-4444   Primary

OUT#ACCEPT 555-555-5555   Secondary

NET 2

OUT#ACCEPT 555-555-5555   Primary

OUT#ACCEPT 444-444-4444   Secondary

Hope this helps,

Patrick

[hes]

Awesome. That is exactly what I was looking for thanks.

[hes]

Turns out my setup is actually more complicated and my simplified example wasn't quite enough once tested. The issue is that the Primary route of 555-555-5555 Is connected to USER 1 on my 2nd Atlas 550 which is then routed out NET 1 on that 2nd Atlas to the telco. When NET 1 on atlas 2 is down calls are not redirected to NET1 on Atlas 1 as Atlas 1 NET2 is not down.

Should I switch NET 2 Atlas 1 so that its user1 and change user1 on atlas 2 to net1? This setup was designed for redundancy so traffic originates from both directions and is routed both directions across these linked Adtran units

ATLAS 550 #1

NET1

OUT#ACCEPT 444-444-4444   Primary

OUT#ACCEPT 555-555-5555   Secondary

NET 2

OUT#ACCEPT 555-555-5555   Primary

OUT#ACCEPT 444-444-4444   Secondary

NOTE NET2 Above is connected to User 1 Below.

ATLAS 550 #2

USER 1

IN#ACCEPT

NET 1

Out#Accept     $     Primary

Hopefully this makes sense.

Thanks.

[Anonymous]

The main issue is that each interface on the ATLAS is independent and if one interface goes into alarm, none of the other interfaces go into alarm.

So when the Net1 port on ATLAS #2 goes into alarm, there is no alarm sent out Net2 toward ATLAS #1. I don't believe changing USER/NETWORK will make a difference in your setup / call routing. There is no way to make an interface status dependent on another interface in the ATLAS.

The only thing I can think of, is to set up the DIAL PLAN to allow the call to be routed back to ATLAS 1 if Network connection is down, but then you'd have to use Source ID's in order to prevent a routing loop where the call keeps getting passed between the two ATLAS 550s until the connecting PRI is full. However if you are routing calls from one ATLAS to the other, setting this up on the existing PRI connection could prevent the call from routing back if the desired Network connection is down. It may require a second connection between the 550s that is ONLY used when the network connection is down, and that connection would be given a different Source ID (like SID=1) so that calls that come into the ATLAS on that PRI are then only routed to the Network connection to the telephone company.

This is probably confusing, but I don't know of another way.