Author Topic: specific extension ignoring call forwarding when dialing specific extension  (Read 2681 times)

Offline APM

  • Contributer
  • *
  • Posts: 14
  • Country: gb
  • Karma: +0/-0
    • View Profile
Hi All,

We have a 3300 and are experiencing some odd behaviour that I hope someone has an idea as to the cause.

When extension 'A' has any/all call forwarding engaged, calls to this extension both internal and external correctly divert EXCEPT for calls from one specific extension ('B').  Calls made from extension B seem to be ignoring the call forwarding and ringing extension A directly.

If extension B calls any other extension with call forwarding engaged, the forwarding works as expected.  So it seems to be a specific extension ignoring call forwarding when dialling another specific extension.

Any ideas guys?


Online ralph

  • Mitel Forums Admin
  • Hero Member
  • *****
  • Posts: 5767
  • Country: us
  • Karma: +469/-0
  • Published Author: http://amzn.to/2dcYSY5
    • View Profile
Does extension B have extension A as a key appearance on it? (or B on A?)
Does ext B and A appear in a ring group together?
Or does A forward to a button that appears on B?

Ralph

Offline Mattmayn

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1069
  • Country: vi
  • Karma: +14/-0
    • View Profile
Are you running anything like UCA? I think there are some routing rules in the client for how to handle specific callers.

Offline APM

  • Contributer
  • *
  • Posts: 14
  • Country: gb
  • Karma: +0/-0
    • View Profile
Hi guys,

Thanks for the responses.

In brief response to your questions:

The extension A appears as a DSS/Busy Lamp key on extension B.
Extension B is in a ring group with extension C but not extension A (extension A forwards to the ring group containing B + C).
Extension A does not forward to a button appearing on B.

We are not using UCA.

After Ralph's query regarding the keys I decided to remove the DSS/Busy Lamp key as a test.  This corrected the issue and extension B was no longer able to bypass extension A's call forwarding.  I then re-inserted the DSS/Busy Lamp key expecting it to cause the unwanted behaviour again; however this has not happened and extension B is still unable bypass the call forwarding on extension A.

So it would seem, problem solved. My only question is, is this known bug (hence the queries around key assignments)?

Regardless, thanks for the help - much appreciated!

Online ralph

  • Mitel Forums Admin
  • Hero Member
  • *****
  • Posts: 5767
  • Country: us
  • Karma: +469/-0
  • Published Author: http://amzn.to/2dcYSY5
    • View Profile
Bug?  Dunno.
Sometimes things get into a "weird" state.
The fix for weird states is often to start deleting things and recreating them.

Glad you got it sorted.

Ralph

Offline lundah

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1216
  • Country: us
  • Karma: +66/-0
  • Senior Chief Grunt
    • View Profile
I'd be curious to see what happens the next time the DBMS check runs.

Offline marcolive

  • Full Member
  • ***
  • Posts: 131
  • Karma: +2/-0
    • View Profile
Reboots are not bad too!  :)


 

Sitemap 1 2 3 4 5 6 7 8 9 10