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 Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Networked MICS and weird Answer DN behavior--Fixed 1

Status
Not open for further replies.

chirkware

IS-IT--Management
Jan 17, 2006
80
US
These forums are great...I always get my problem fixed quick. This time, as I was describing the below situation, I figured out the problem. As the solution was not obvious, I decided to go ahead and send the description of the problem and the solution in hopes it helps others.

SITUATION:
Two MICS (7.0/7.1) networked via T1. On MICS1 there was an Answer DN setup so that ext 222 could answer incoming calls for 221. That Answer DN setting was removed, and all seemed well. Later, a call forwarding on busy setting was added for 222.

Calls from MICS2 behave properly calling 221 EXCEPT that, when 222 is busy, calls dialed from MICS2 to 221 are following 222's CFB settings.

I have verified that incoming calls from the outside world and calls from other extensions are behaving properly...it's only calls from MICS2.

I looked at the target line for 221 under Line Access for 222, and it does not show up.


SOLUTION:
The target line for 221 was set as Private to 221. I changed it to Public. Eureka! Now, looking at Line Access for 222, there is 221's target line, set as Ring only. I removed it, then changed the target line for 221 back to Private to 221.

And all is well!

So...if a target line is set to private, it can still be accessed by another extension...and it won't show up under their Line Access.

Now, the 222 extension stays busy all the time (literally...it is intentionally kept off hook...see thread181-27567), so this was a major problem for me (especially since x221 is the IT person for the company...me...and 20 of my co-workers could not call me. Hehe, boy was it nice not getting those extra calls though...lol).
 
now thats what is called a 'bug'
thanks for posting the fix ... you'll be a star for someone who is stuck on this (their billing might suffer though :)
 
I'm not sure why my thread reference above went where it did...correct thread reference is to thread799-1463422
 
This only happens if it's applied to a set, and then you mark it as Private. You think it would erase off all DNs, but doesn't. If it was Private first, you wouldn't be able to add it.

Great troubleshooting.

Adversity is Opportunity
 
senk1s...I believe they prefer "undocumented feature". :)

Dewey...I'm trying to remember if I had to manually add line access to x221's target line in order for x222 to be able to answer calls from across the T1. Any idea whether adding an Answer DN for an extension with a target line automatically adds access for that target line? I'm thinking it did, because had I changed it manually, I would have had to set the target line as public, and I can't imagine I would have subsequently changed it back to private (and besides, that would make it "my fault"...nah, that can't be it!).
 
Adding an Answer DN should not automatically add the Target Line. But, adding an Answer DN when the line is Private won't ring the extra set. So, It would had to have been Public to make the set ring via Answer DN, or made Public to add the Target Line.

How it became Private again, I wouldn't want to speculate.

Adversity is Opportunity
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top