The Adtran community holiday season is starting next week! The holiday period will span from December 21, 2024 to January 6, 2025. During this time, responses to feedback form submissions may be delayed. If you are encountering product issues, you can reach out to Adtran support at any time.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
crennie
New Contributor

Making out going calls thru adtran, currently one way calls

I have call one way now threw the Atlas 830 unit.

PBX to Adtran to Redcom (yes)

Redcom to Adtran to PBX (no)

Logs attached I dial a 9 for out side with 4 digit extension (3668) Get a ringing but 3668 is not ringing. I few that it is the PBX put would like to review the log for Adtran problems

Oct  1 17:01:56 Adtran ATLAS 830[ADTRAN]:L2-Formatted|1|3|Recd = Sapi:00  C/R:R Tei:00

Oct  1 17:01:56 Adtran ATLAS 830[ADTRAN]:L2-Formatted|1|3|       Ctl:INFO     Ns:11   Nr:48

Oct  1 17:01:56 Adtran ATLAS 830[ADTRAN]:L2-Formatted|1|3|       Prot:08  CRL:2  CRV:8002

Oct  1 17:01:56 Adtran ATLAS 830[ADTRAN]:L2-Formatted|1|3|       M - 45 DISCONNECT 

Oct  1 17:01:56 Adtran ATLAS 830[ADTRAN]:L2-Formatted|1|3|        IE - 08 CAUSE               Len=2

Oct  1 17:01:56 Adtran ATLAS 830[ADTRAN]:L2-Formatted|1|3|             80 Location:U

Oct  1 17:01:56 Adtran ATLAS 830[ADTRAN]:L2-Formatted|1|3|             81 Cause:UNASSIGNED_NUMBER

Oct  1 17:01:56 Adtran ATLAS 830[ADTRAN]:ISDN|1|3|Call clearing: UNASSIGNED_NUMBER : Loc=U

Oct  1 17:01:56 Adtran ATLAS 830[ADTRAN]:ISDN|1|3|Call to '3668' failed

Oct  1 17:01:56 Adtran ATLAS 830[ADTRAN]:ISDN|1|3|Call to '3668' busy after switchboard has connected it.

Oct  1 17:01:56 Adtran ATLAS 830[ADTRAN]:ISDN|1|3|Busy destination: UNSPECIFIED_CAUSE : Loc=LN

0 Kudos
5 Replies
Anonymous
Not applicable

Re: Making out going calls thru adtran, currently one way calls

There seems to be an issue with the IN#ACCEPT lists in the ATLAS. The call to 3668 comes to the ATLAS on S1.3 and is routed back out S1.3 rather than out S2.1 to the PBX. So it is being directed back to the Redcom which then disconnects with a cause UNASSIGNED_NUMBER.

So somehow the IN#ACCEPT for S1.3 is a better match for "3668" than what you have as the IN#ACCEPT for S2.1.

Anonymous
Not applicable

Re: Making out going calls thru adtran, currently one way calls

Looking at the screen shots of your other ticket, both S1.3 and S2.1 have an IN#ACCEPT of 3XXX. The ATLAS does start at the top of the DIAL PLAN list and looks for the first, best match, so S1.3 will match first.

If possible you can modify the IN#ACCEPT lists to be MORE specific so calls won't be routed to the wrong end device. For calls in this log, you can have S1.3 have an IN#ACCEPT of 35XX and S2.1 use 36XX, but that is just a suggestion.

crennie
New Contributor

Re: Making out going calls thru adtran, currently one way calls

I think that I have my T-1's connect wrong, can you answer this?

We are using this for switch over to the Redcom unit (Network Term)

We are going to have on T-1 from the PSTN network to the Adtran User Term, another from the Adtran to a Audiocodes M3K User Term and then into a sipXecs.

If the Audiocodes has a major failure we want the PSTN sent to the Redcom via the Adtran, we are under the impression that the call would be routed to the M3K using dial table, if the M3K is not working or Adtran gets no reply the call would be sent to the Redcom.

Anonymous
Not applicable

Re: Making out going calls thru adtran, currently one way calls

A T1/PRI from the PSTN should be a NETWORK TERM in the ATLAS. The PSTN is the network, so the ATLAS is terminating to the network (and acting in a USER role). If it is a PRI and the D-channel is active then it is the correct configuration but would be a very unusual situation.

If the call comes into the ATLAS from the PSTN and the PRI to the M3K and the Redcom have the same IN#ACCEPT lists, then the ATLAS will route the call to the first available entry in the DIAL PLAN. By "available" I mean that the D-channel is active and the ATLAS sees channels not in use. If the PRI is down or all the channels are in use, then it will look for the next match, which should be the Redcom.

If, however the ATLAS sees the M3K as available and routes the call out that PRI, then the ATLAS is done with its routing and if the M3K does not respond or returns with a BUSY on its end then the call is "busy". Once the ATLAS routes the call, it is done with its routing function and will not attempt to re-route based on the response from the end equipment.

Anonymous
Not applicable

Re: Making out going calls thru adtran, currently one way calls

I believe you called into ADTRAN Support and worked with me over the phone. As I recall there were some configuration changes we had to do, but I'm going to mark this ticket as "assumed answered". If you have any additional questions you can change the status and post your questions.