Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Second call to AA line unanswered

Status
Not open for further replies.

TGW

Technical User
Aug 9, 2004
27
US
We just switched T1 providers, and now if more than one call comes into a single line with AA (0 rings) on in our NAM that call goes busy or simply rings.....

The primary NAM DN is 294, and it is not set to fw on busy or fna. KSU 0x32 software R1T1; Nam Norstar VM 1.2E. The NAM isn't busy, and neither is the T1. The first call works, and the subsequent calls hit our system, but don't get routed properly if it's an AA-only line.

There must be something I did wrong or didn't do, but I can't find where it's going wrong. Any ideas?
 
Sounds to me like you need to program multiple appearances of your main target line onto ext. 294.
 
Assign in the Nams AA menu under lines the other lines.ow many lines are in the hunt?T1 or PRI?
 
T1, not PRI. 12 channels provisioned on T1, and uses received number. No hunt.

I can try multiple line appearances on the NAM, but currently there are none, and in the F-983 menu it's set to AA target line 150, which has a received number of 0520.
 
With the prime line assigned, it goes to gen. delivery if enabled or "The person you have called is not available" if general delivery mailbox is not enabled. Would a problem passing the received number to the NAM be the trouble?

Setting L150 to Appr&Ring on set 294 did not help.
 
Have you checked under ACCESS2 programming to verify it's not a bad port? Usually a reboot will fix that.
 
It wouldn't make sense to have a bad port, because calls to other numbers (but only one call at a time per target line) will auto-answer properly, even though further calls to L150 will not complete.

I couldn't find the port status on this; the feature code is F918, The password is a*****2, and the proper menu seems to come up, but with no port status readout available. The log shows that ports 0-5 came up at reboot.

Do you think the NAM is in need of a re-install? Unfortunately, there's no backup that I know of on site.
 
Just for grins and giggles, try changing the rings from 0 to 1 under Lines in the NAM. I had an issue several years ago where I had to change the rings from 0 to 1 to fix it but I don't remember what the problem was. I've slept too much since then.

War Eagle!
Lions Baseball '09!
 
I tried changing the rings from 0 to 1, and it seemed to have no effect.

I talked to our vendor today and he just said the R1T1 and 1.2E on the NAM was old, told me that the newest was 7.1 (which I knew), told me he figured out a workaround, but forgot what it was, and practically said he'd have to get paid to do anything useful.

I don't think I can do multiple appearances of one line.

I plan to try having TelePacific do a rollover digitmod so each call will hit a different target line for multiple calls. If they can do this, I expect AA to work like new.
 
Since this is a T1 check the trunks that are on the T1 either DID trunks or E&M and check the prime for them.
 
DID. Prime to the NAM does not help (the person you have called is unavailable or mailbox full if the gen delivery is on but not initialised).

Speaking of, how do I make all channels E&M so I can use them for both incoming and outgoing? I tried E&M, but incoming calls fail when I do.
 
We're still stuck with the original problem. Does anyone know what the proper workaround is for this thing to answer more than one call per line?

Is there a troubleshooting feature like a call trap to find why these are going where they do?
 
you said the FNA and FBUSY. WHAT ABOUT BUSY ON DND which is a station feature program. Outbound on trunks can be restricted by the Central Office unless you do not have it in a Pool group.
 
I don't think there's a DND ON BUSY feature on this system, if so, I can't find it. I had a vendor look at it yesterday, and all he could figure was a reinitialization of the NAM, which I'd rather not do if possible.

I am now sure that the second call is hitting the NAM if it's the prime set, going to B2 (extension 422, the other side of 294).

HELP! still in the same spot.
 
0 or 1 as a first digit could be a problem. I was always trained not to use those as first digits. I always use 7 digits for receiving to prevent collisions with a second phone number. A current system Toshiba, we replaced with the Norstar and the last company had the CO change the sending digits when six lines had 0 or 1 as the first sending digit. Instead of a 0845, the CO changed the sending digits to 8845. I;ll have to check that system to see if they have any non used number with a zero first and install it to see if i can duplicate your problem.
 
We have a line with suffix of 9870, with digit mod to 8870. I'll try that line for testing. Another line with Rec'd # of 8059 is doing the same mischief, however.
 
Okay, the problem's gone now that I put in a new NAM 4.1.

Thanks, all!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top