VM Failed to Pick Up FCNA

[jpang102]

An extension number is not forwarding calls to VM although "Forward no answer" was set up correctly under "Capabilities". While calling that extension number, my display shows that the call is forwarded to an non-exist extension. My call is then dropped, instead of being forwarded to VM. Changing the number to be forwarded to has no effect. Always, the non-exist number takes precedence.

Later, I changed the no. of rings from "4" to "3". VM started to pick up. It is just a workaround because somewhere it must have been set up to forward to the unknown number on 4 rings. But I cannot locate where the configuration was stored.

Also, the DN has a DID number attached. When calling that DID, it does the same thing. After 4 rings, the call is dropped. I don't know how to adjust the number or rings or how to make changes on FCNA.

 

[Deweyhumbolt]

Make sure another DN does not have this problem DN as an Answer DN. That would make the other DN the controlling telephone. Hence, problem disappears when ring is at 3, one in front of other DN.

Adversity is Opportunity

 

[xjswx]

This is a dumb question, but has to be asked:

Did you make sure that the extension in question has not been forwarded?

 

[jpang102]

Two questions are spawned. Is there an easy way to verify how if this DN was set up as an answer DN for another number? I can adjust the number of rings for FCNA for the DN to reduce it to 3. But this has no effect on DID calls. How can I make a similar adjustment to inbound calls to this DID?

 

[jpang102]

xjswx,

I checked the phone unit and the system config. No forwarding is in effect.

 

[xjswx]

I would start with checking the "non existant" extension. As far as I know, you cannot forward a set to something that is not working.

What kind of system is this? MICS, CICS, 8x24?

 

[jpang102]

The so called "non-existant" extension was the old extension number for the VM system. The installer changed it when we re-configured the system.

I believe it is an MICS 3.0 or 4.0.

 

[xjswx]

Verify your voicemail DN by using F985.

Go back to the set in question and change the Fwd no answer to none.
Release from programming.
Again go back to the programming of the set in question and change the Fwd no answer to the DN you got from F985.
Check you Forward delay and make sure it's set the the correct number of rings you want.
Check Fwd on busy and make sure that is set to none.
Check you target line as well to make sure that the control set is the extension you have it assigned to.
Not knowing what programming platform you are using, I would call the set and listen to see if any other sets ring at the same time, that might let you know it the answer DN is set up on other phones.

Try that for a start if you haven't already.

You might also want to restart the system. That might clear any issues.

 

[jpang102]

xjswx,

I have done what you suggested but still have no idea what is going on.

>>Go back to the set in question and change the Fwd no answer to none. Release from programming.
Done. After setting FCNA to none, when I called that DN again, at 4 rings, I was forwarded to the non-existant extension 5580 and then the line dropped.

>>Again go back to the programming of the set in question and change the Fwd no answer to the DN you got from F985.
Done. Set to ext to VM number 5644, just as all other lines were configured.

>>Check you Forward delay and make sure it's set the the correct number of rings you want.
Standard - 4 rings

>>Check Fwd on busy and make sure that is set to none.
Checked, Fwd on busy -> None

>>Check you target line as well to make sure that the control set is the extension you have it assigned to.
Confirmed. Settings are fine.

>>Not knowing what programming platform you are using, I would call the set and listen to see if any other sets ring at the same time, that might let you know it the answer DN is set up on other phones.
Again, it is a MICS 4.0. I checked maintenance. System Version is SP: 30BJG06 NAT

After doing the above, nothing changed. My call will be forwarded to the old VM extension of 5580 and then dropped. If I shorten the number of rings for Fwd No Ans to "3", then it works. VM (at 5644) will pick up correctly. I called x5644, it showed "not in service".

 

[Deweyhumbolt]

I still think it's an Answer DN issue. Especially, since I now know that non-existant DN was the old Vmail pilot DN. You can't have an Answer DN on an analog port, so it has to be a TDM telephone with an Answer DN for your problem DN. Have you rebooted the switch? can't hurt.

Adversity is Opportunity

 

[jpang102]

I rebooted it numerous time already. Like other lines in the office, there is no line assigned to "Answer DNs" under Line Access. Other lines work fine still.

 

[MarvO1]

You need to look at the programming of the non-existing DN.
I believe Dewey is on the path. Undocumented Answer DN keys can be a pain to find sometimes.

MarvO said it

 

[jpang102]

Good point. I will check the non-existant DN on my next trip. After I change the delay to 3 rings, VM now picks up before routed to the bad DN.

 

[Deweyhumbolt]

The only way is to go into Answer DN programming for every Active set. Time-consuming, but guarranteed victory.

Adversity is Opportunity