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!

Centralized Mail Problem

Status
Not open for further replies.

flctech

Vendor
Oct 27, 2004
21
CA
I have networked two MICS's 6.1xc and a NAM 4.1 used as Centralized Mail.

My problem is that some calls to main Target Lines that should be answered by AA are going directly into mailboxes.

I read that this problem on a non-centalized mail system can be resolved by changing the Redirect DN to "N". I don't think this can be done with Centralized mail as this is required to provide remote site users direct access to their mailboxes.

Has anyone come across this before and do you have any suggestions?

Many Thanks in advance.
 
Do you have REC digits on those lines that match mailboxes built or do they just go to random boxes?
 
I seem to get random mailboxes.

Each DN has a target line assigned to ring only on the set and matches the DN exactly. eg ext 5756 has target line 234 with REC digits of 5756. I suspect that the Redirect DN function in the mail is routing outside calls directly to mailboxes for some unknown reason.

I tested it again this morning and reached 4 different mailboxes even though I called the main number and used the same line to call in. The main number is target line 157 and does not appear or ring on any extention.

Really confused on this one.
 
I was looking over your information and found a common problem with Nortel you are doing... You have the recieved digits match extension numbers and this is a no no on Norstar systems if you want problems like this..... Yes I know what you are thinking I always match recieved numbers with extensions for some reason when this happens I make the recieverd different then the extension and all problem disappear........
 
Tom215,

Thanks for your reply.

These two systems are connected via TIE cable using a second PRI card at each site (They are across the street from each other)

In order to provide the ability to reach callers in each site by dialing their ext is to align their DN with target lines that match their DN's. This works very well. The actual DID's that come in from outside however do not match their DN's. This was resolved by digit substitution provided by their carrier.

eg.

DID (xxx)xxx-8743
Carrier transmits 6743 (4 digit rec'd length)
TL 255 rec'd# 6743
DN 6743 assigned Line 255 Apear only

Caller from same system dials I/C 6743 gets party
Caller from remote system dials I/C 6743
6 is route code to use TIE Cable
Absorb Length is set to "0"
Host site picks up rec'd digits of 6743 and send the call to ext 6743

Not sure if this makes sense but it works really well.

There are other posts that address this issue of mailboxes picking up AA calls at random and the solution has always been to Disable the Redirect DN in the voicemail. My problem is that I can't as it is required to allow remote site users to login to their mailbox.

Thanks again for your reply. Any other thoughts?
 
I am having the exact problem with my customer. Also centralized voice mail. Customer uses a backdoor DID for AA. After hours coppers get answered by AA - same problem on the coppers - one in 20 or 30 calls will go directly to random voice mails. No pattern can be seen. ITAS took this issue to design and could not find any problems with the logs or programming. When I pushed for futher resolution, tech had nothing for me. I am wondering if this is a known problem with Centralized VM on the NAM and they are just chalking it up as an MD product, and are not trying to resolve the issues. If anyone has any resolution or ideas, I would also be greatly interested.
 
Gecko202002,

I'm sorry you're having the same problem however I'm glad to see that it's not just me.

I have spent several weeks looking into this one and no one seems to have an answer. I've been looking at this from the Redirect DN angle. If we turn the Redirect DN off the problem does dis-appear (made 150 consecutive calls with no re-occurance of the problem)however remote users get put to General delivery when they call the VMail prime DN (Normally they would get right into their personal mailboxes)

This leads me to beleive that the system is occasionally treating outside calls based on Rec'vd Digits as an internal call and the Redirect DN routes the call to the mailbox. I've been trying to figure out if this can be purposely manipulated with the intent to filter the problem out. I'm not sure if that makes sense but I think there might be a way to re-produce the problem in order to find a resolution. I noticed that I get a higher frequency of misdirected calls when calling from a diferrent number in my hunt group than with others. Maybe CLID plays a part in this?

Any thoughts?

FLCtech
 
Last I spoke with Nortel - Itas tech said to try the voice mail patch. NVM 4.1.05 with Access 6.02H. I am waiting for access to the patch and then I will load it. I will keep you posted if this clears the issue.
 
gecko202002,

Nortel's site has NVM 4.1.05 with Access 6.02H (374mb) and the 4.1.05 upgrade 1033kb.

Is there a way to determine what Access version the NAM has and is the upgrade all that is required? or do I need to reinstall the software using the version with Access 6.02H? I don't see a reference to these being a patch.

I'll download and look at the readme files. Will post what I find.

flctech

 
Go into config > Maintenance > Port/DN status - show the lead port for voice mail > show that - then show Version - you will probably see A60200G - which means you are at Access version 6.02G
As far as the software on their site - I think it is the full software - I know in the past when I had to update the Access it was a pretty small file - based on this, it looks like the full blown.
I will contact ITAS again to find out the full details - I am not too happy about doing the full blown software - nor do I think I will be able to download the full file without corruption.
I'll let you know.
 
Had the same problem and did an access upgrade to H and problem solved. it was quite irritating getting to that point but the upgrade took minimal time (bout a 1/2 hour total) I only had to update the access version. Good luck but I am sure that this will fix your problems.

----------------------------
JerryReeve
Communications Systems Int'l
com-sys.com

 
Gecko202002 and Jerryreeve,

Thank you for your replies,

How would I go about just upgrading the Access version? I've downloaded the full version but didn't see an upgrade for just the Access 6.02H. Is this an option promted during the upgrade or do I have the wrong patch?

Appreciate your help.

Flctech
 
According to ITAS you have to load the full version - there is no access patch. So you have the right software.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top