sundance-communications.com/forum Forums TDM Business Telephone Systems Nortel Telephones & Systems VM transfer has me stumped, rats, darn, shucks, etc.

MICS 6.1, NAM 4.1 (I think) everything flawless except one extension, 2034 forwards to voicemail (2222) should go to mb 2034 and one second later the call is in the Gen. Delivery mb.

Tried [Feature] # 4, tried [Feature] # 8 7 1, deleted mailbox, recreated it with same problem, changed FNA to 6 rings, to 2 rings and no change.

Control set for set 2034 is 2034. No restrictions I can find. Set is unlocked. Everything I can see in programming is identical to the others.

I'm not often stumped after attacking from every angle I can think of and after two hours (yes I am that stubborn and no it is not billable time if I can't fix it) of determination that it would not beat me, it did.

Any good ideas?

Er.. no expert but does 2222 have a ringin answer DN of 2034 ?

tmorin has a possible cause. Also I've seen NAM's do stupid things that only a reboot will cure.

2034 had no answer DNs, can check 2222 for answer DNs. Thanks

Had not tried rebooting, not a flicker of anything wrong in NAM except this one station forwarding to VM box and then almost instantaneously opens up the General Delivery mailbox. Very weird. Thanks

We telcom people are used to dealing in absolutes! It's either go or no go, black and white. By and large the equipment we work with operates in such a manner. When faced with an indeterminate or gray area we tend to put the blinders on and our quest begins. If, in your case, all programming is correct and the proverbial power cycle fails to correct an issue, then you've found a clitch or a problem. Assign a new extension and move on! Life is way too short.

Check more extensions than just 2222. Any forwarded extension with a ringing Answer DN for x2034 could cause this problem.

While you're cycling power, you may as well do the MICS too. I know you've been doing this long enough to know how susceptible Norstars are to power quality issues.

Thank you so, so much for the humor jwooten, I needed that, this has just become one of those Man of La Mancha deals, to win the unwinnable dream of a perfectly operating MICS that just loves to pee in my face and tell me it is raining.

Thanks, BCM I will try that Monday.

There are times when I just simply do not know how something is supposed to work and I have no shame in asking. Every single thing I have checked is IDENTICAL in programming to this box.

I should have gotten stoned and tried to figure it out but I don't smoke anything and two former employers lost EVERYTHING they owned to coke, so I just behave myself when it comes to drugs.

I had a problem with a MICS 6.1
the customer added a phone after the install was completed so I guessed at a DID/DN number then when I tested it I found the DID was assigned to another company. so I looked up a valid Did number and changed the DN and target line accordingly. tested good. added a vm box and went on to do some other things.The customer came back to me and said that the user could not set up their mailbox that instead of getting the password prompt they were getting log: prompt. On a hunch I added a mailbox with the original DID/DN I had assigned as a test and called vm and sure enough I got the password prompt. Even though I called from the new DN I deleted the test MB reset the vm and the problem cleared. Norstar Vm must use port numbers from the system and compare it to some kind of look up table to determine mailboxes and the phone system had not updated the voice mail when I changed DNs.(hope thats clear)

At your suggestion, I asked the customer to reboot the system. He had a friend of mine RAD into it and it all looked perfect but told my customer not to power down without me being there.

I assumed it was 1000 to 1 it would be cured with a power cycle but I was on site yesterday and we both said, WHY NOT?

Yup, it works perfectly now, that was all it took.

Thank you.

Maybe next time I won't be so stubborn at thinking I can find some bad programming and just power it down.

Again, thank you for the suggestion to power it down and the reinforcement to power it down.

did you do the original programming? if so then how could you possably assume there could be bad programming