Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - APM

Pages: [1]
1
Interesting, it seems to be very much frowned on using a console version that does not match the controller - I'll have to see what my provider says about it, might not be too happy about that method.

Thanks.

2
Hi all,

Our console operators are still running XP in order to be compatible with our outdated software version 3.4/5 (MCD version 9.0.2.18).  As my company is trying to avoid the cost of upgrading the controllers I'm wondering if it is feasible to run the console software in a virtual machine such as Windows 7's 'XP mode' or Virtualbox etc.

Anyone got this running in a live site? Any horror stories?

Thanks.

3
Hi All,

I eventually got to the bottom of this (or rather a Mitel engineer did).  Frankly it started to go over my head a little but the short version is that there was an entry in the 'Class of Restriction group' which meant that the VM system was not allowed to dial a number from our other site.  As our console operators are logically both at the 'other site' this gave the weird behaviour that any local extension could be specified and work, but extensions at the other site would not.

Hope this helps someone in the future!

Thanks again to those who attempted to help :)

4
Hi Ace,

Yes these are exactly 5550 IP consoles.  I'll try the transfer option you mentioned and double check the system speed calls for 0.

Thanks again.

5
Hi Ralph,

I tried changing the extension for the 0 mailbox on my local controller (site B) to a console number, this sadly did not help.  This also had the side effect of upsetting the method the console operator uses to direct a caller to someone's VM box in that the console operator had was requested number/passcode details for the VM system.

I'm afraid I can't quite grasp what you have said in your second line - think there might be a typo or two.

I have however discovered that this problem may only be affecting site B.  I called into a site A extension and VM box on an external connection and the call did forward to the console operator as expected rather than just falling back to voicemail.

I should point out that while we have a controller at both sites and console operators at both sites, both console operators are configured to connect and operate from the site A controller.  I therefore wonder if site B is failing to direct to a console operator because there is no logical console operator for that site (even if they are physically there).

6
Hi guys, thanks for the responses so far.

There are no mailboxes on either controller for numbers 421 or 221.  However each controller has a 0 mailbox.  These did both turn out to be full (as no one had any idea they existed!).  By making room on these boxes the caller no longer receives the 'mail box full' message however prior to that step the call does not appear to go through to the specified console operator either (when the hold music is playing).  This is the principle issue as we don't really want callers to be dumped at a mailbox, we want them to reach a console operator.

The supervised transfer setting is set to false which would be backed up by the fact that when a regular desk extension is specified (rather than a console number) is transfers correctly without further intervention.

So, any ideas on why the consoles don't receive the calls when regular desk extensions do?

Thanks again guys :)

7
Hi All,

I find myself in need of the Mitel sages once again!

We have the 'operator' for some voicemail boxes configured to be that of their secretary.  This works as expected and if a caller presses 0 (instead of leaving a message) they are transferred to the number specified.

The problem is for boxes where we specify the operator as either of our console operator numbers (421 or 221 site dependant).  If a caller presses 0 (instead of leaving a message) the following occurs:

"You are now being transferred to the operator"
~ a few seconds of hold music circa 3 ~
"I'm sorry but no one is available to take your call.  That mailbox is full and cannot accept any new messages.  Please try again at another time".

The caller can then attempt other numbers.  421, 221 and 0 all result in a similar failure.  Keying another number (i.e. a colleague) does work however.  So it seems to me that there is a specific issue with our console operators being specified.

Any ideas guys and girls?

8
The application is Mitel Border Gateway.

Thanks for the info, much appreciated.

9
Hi guys,

Hopefully a straight forward yes/no answer.

I've inherited the 3300 systems at my workplace and wasn't employed here at the time the controllers were sold/installed.  The business owner is under the impression that either by way of a special handset or a PC application it is possible to remotely connect into the 3300 controllers and effectively work remotely making and receiving calls.

Ignoring the networking side of things (VPN, firewall config, bandwidth etc) is this possible or is it a load of BS?

Thanks in advance!

10
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!

11
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?

12
Ralph you absolute legend!

Cluster Element Assignment form
Cluster Element ID Digits column

Prefixed ID digits in front of hunt group number as suggested - worked like a charm!

Thanks for saving me a bunch a Christmas hassle!  ;D

13
Hi Mattmayn, thanks for the response.

The only number I am aware of to access the VM system is the hunt group number (555) however this is the same for both controllers.  Is there something I am over looking?  Is the pilot number different? Is there a place I can look to establish the pilot number?

Much appreciated.

14
Hi All,

Another Mitel noob here in need of help!  Hopefully this is a simple one.

My company has 2 offices each with their own controller and subnet.  Our night service voice mailbox is located at the opposite site to me.  When I attempt to login in to the associated mailbox number from my site, it is not recognised.  How can I access the mailbox without physically going to the other site?

Thank you.

Pages: [1]