ADTRAN ATLAS 550 Back to Back phone call switching

[Anonymous]

Hello.

I am working on a rather large voice lab. I have two ATLAS 550, one with 4x Quad-PRI cards and a T1/PRI card in Network Slot 2 (Called VoiceSw1), and another ATLAS 550 with four Octal FXS cards and a T1/PRI card in Network Slot 2 (Called VoiceSw2)

VoiceSw1 has a bunch of routers connected to it via VWIC-T1 cards

VoiceSw2 provides lines to connect to FXO cards in other routers, as well as several lines I use to emulate phones on the PSTN (LD, Toll, Premium, Intl)...

The problem is I don't understand how to configure ROUTING between the boxes.

I have selected VoiceSw1 to be the Network Term for the connection to VoiceSw2 (the User Term).

On the NETWORK TERM side, I understand that the OUT#ACCEPT basically sets the matching patterns or specific numbers that will be routed out of the selected interface.

On the USER TERM side, I understand that the IN#ACCEPT sets the numbers that will be accepted inbound on the selected interface.

So I THINK I have it figured out going in one direction. The issue is I don't understand how to set (if it is necessary) routing in the other direction (from the User Term to the Network Term).

Any assistance is greatly appreciated!

[Anonymous]

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

It might be a little confusing, but both the OUT#ACCEPT and IN#ACCEPT lists under the DIAL PLAN are EGRESS from the ATLAS. So they are how the ATLAS routes a call out to another device routing it out the specified interface.

The NET TERM uses OUT#ACCEPT because it is generally intended to connect to the PSTN Network - so a call would be going OUT to the public network.

The USER TERM uses IN#ACCEPT because it is generally intended to connect to user equipment - so a call would be coming IN to the customer's end device.

Both the IN#ACCEPT and OUT#ACCEPT serve the same purpose, as they define what calls are routed out of the ATLAS on the specified interface.

Hope this helps,

Patrick

[Anonymous]

I went ahead and flagged this post as "Assumed Answered". If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons. This will make them visible and help other members of the community find solutions more easily. If you have any additional information on this that others may benefit from, please come back to this post to provide an update. If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

Mark

[Anonymous]

Patrick

Sorry for the delay in answering,

I'm working on this, and it seems like it's ALMOST there. Here is my basic topology (the dial plans give you an idea of the size of this lab; basically the odd numbers are on a T1 and the even numbers are on an FXS port)

The T1 between ATLAS1 and ATLAS2 is using the Network service slots, while the T1 between the router and ATLAS1 is using a port from a QuadT1/PRI board

I'm using a $ pattern on the T1 between the ATLAS; the assumption is that anything that doesn't match a directly connected pattern will follow the $...

Calls from 0700 to 911 work. Calls from 0700 to 18082089999 do not work. Calls from 911 to 18082089999 work.

When I debug on router 7, I can see digits being sent onto the T1. Debugs on router 8 show no incoming digits when 0700 calls, only when 911 calls.

Does any of this make sense?

[Anonymous · Accepted solution]

I have hacked at this for a while today and have come up with some answers.

First, on the inter-ADTRAN t1, the leading "1" is stripped by the first ADTRAN. Since I had the "1" as a part of the IN#ACCEPT and OUT#ACCEPT fields, there were no matches. So now all of the IN#ACCEPT and OUT#ACCEPT field reflect a 10-digit number, and I can call back and forth to the 8xx2xxXXXX numbers successfully by dialing 18xx2xxXXXX.

Now my problem is the "international" number I have configured on ADTRAN2 isn't reachable.

With the "national" numbers, the leading 1 is stripped and all is well. With the "international" number, the leading 011 is not stripped by the first ADTRAN; it is delivered to the second ADTRAN intact (the full number; in this case 011496217246223).

To find all this, I had to move my "outbound" T1 to another port and connect a router to it and debug the ISDN q931 messages so I could see the received digits. I couldn't find any way to see call routing information on the ADTRAN using either SYSLOG or a DEBUG of some sort.

So the full number is being delivered to the second ADTRAN, and there is an FXS port with the IN#ACCEPT field set to 011496217246223, but no calls are completed.

I played with the IN#ACCEPT field and added 496217246223 , 62172462223, and 7246223 as alternatives. ALL of those strings will get routed correctly. So it seems that even though the IN#ACCEPT field has an entry of 011496217246223, when ADTRAN2 receives those digits inbound on the T1, it doesn't know what to do with them.

Again, I can't find any setting that will cause the SYSLOG to show call information, included failed calls and dialed strings.

In both ADTRAN1 and ADTRAN2, the "number type template" has an entry for international numbers ( 011 X$ ).
The inter-ADTRAN T1 is set up to forward all digits, so I know nothing is being lost there.
On the NETTERM side (which is ADTRAN2, not ADTRAN1 as specified in the diagram), The T1 Interface Configuration field "Outgoing Number Conv." is set to "As dialed" (changed from the default "ISDN National-as dialed").

Any suggestions?

[Anonymous]

As far as the ATLAS stripping off the "1" on the number, that sounds like the NUMBER TYPE TEMP (under the DIAL PLAN and GLOBAL PARAM). The NUMBER TYPE TEMPLATE is used when the NETWORK TERM PRI is configured with the "Outgoing Number Conv." set to "As Dialed". If there is no NETWORK TERM PRI then "As Dialed" is the default.

Under the NUMBER TYPE TEMPLATE anything under the PREFIX column gets stripped off. So if you want the full number transmitted then the "1" should be removed from the PREFIX colum, and added to the PATTERN. So the PATTERN will go from "(NXX) NXX-XXXX" to "1 (NXX) NXX-XXXX" (with nothing in the PREFIX column).

So to strip off the "011" on an international call, the PREFIX column should have the "011" and then the PATTERN will be "X$" (because the length of international numbers varies). In order to send the "011" then the PREFIX should be empty and the PATTERN should be "011 X$".

To monitor the switchboard and the digits, under SYSTEM CONFIG and EVENT LOGGING, you can set SWITCHBOARD to INFO, as well as ISDN EVENTS, and you may need to set ISDN L2 FORMATTED to INFO as well. (ISDN L2 FORMATTED will give you the full Q.931 logging, converted into an "English-type" print-out.)

[Anonymous]

Patrick,

I am tracking on how the prefix and number template impacts "national" calls, but international calls are acting really weird.

No changes from the previous configurations, so the standard templates are in place, but the international call seems to not only NOT have 011 stripped, but have an extra 011 added.

Attached are edited syslogs from the Router and the ADTRANs. I first made a call to 911 as a control call (worked fine); then the call to the international number. The line 0700 is dialing 9011496217246223, with router 7 stripping the 9 and sending the rest (as you see in the router debug output). Then on the ADTRAN you see 011011496217246223 as an input string; no idea where that is coming from.

[Anonymous · Accepted solution]

In the ATLAS, change the NUMBER TYPE from INTERNATIONAL to UNKNOWN, and see if that helps.

[Anonymous]

That did it!

Thanks so much for your help