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 - adambpa

Pages: [1]
1
Yes, I simply removed it from the voicemail hunt group 1 and inserted into the AA hunt group 3.  When setup as a circular hunt group, every other time you call in, you get a different greeting.  RAD group, system greeting, rad group, system greeting, etc.

2
Hello,

Yes, I am trying to use two ports from the middle of the range of voicemail DNs, in this case, 374 & 375 out of 371-378.   Currently all voicemail ports even the port I am using for the AA hunt group have COS 7 which is the voicemail COS.  That port works by itself so I'm not sure why that would impact the second port since they are both using the same COS.

Thank you,
Adam

3
Hello,

We deal mainly with 3300 and 250s but have assumed support of an SX200 ICP AX with 6 analog trunks.    We implemented an auto attendant using a circular hunt group and a RAD group.  We pulled one of the voicemail port extensions out of the primary voicemail hunt group to use for the RAD device which works fine.  We tried pulling a second port to handle concurrent calls to the AA and it seems that whenever a call hits the second port, we receive the system greeting instead of the RAD group messages.  If we leave only the one port, the RAD group plays every time but can't handle concurrent calls.  Any SX 200 expert advice on how to solve this?

-Adam

4
MiVoice Office 250/Mitel 5000 / Re: ACD Huntgroup Recall
« on: April 11, 2021, 07:49:52 PM »
Things I have tried with no luck.

  • Creating a UCD huntgroup with an extension list containing the two phones that the ACD agents would normally use and another huntgroup member list containing those two users as well as local and off-node extensions that they would like the calls to overflow to.
    When testing this, even though the huntgroup is setup as linear, it seems to ring all members of both lists at the same time.
  • Keeping the initial ACD setup and using Overflow timer/destination instead of recall.  This had no effect and calls still stay camped on first group even though all agents are logged out.
    I wasn't totally surprised by this as the feature and programming guide states that the Overflow timer is not used on ACD groups.

5
MiVoice Office 250/Mitel 5000 / Re: ACD Huntgroup Recall
« on: April 06, 2021, 04:16:22 PM »
If there is no other way, we can switch it.  We were hoping to use some ACD features such as longest idle/wrap up timer, but if there are no other options, we can change it to circular hunting I suppose.  Are you saying that if it is UCD that the recall would work differently based on either DND or hunt group remove?


6
MiVoice Office 250/Mitel 5000 / ACD Huntgroup Recall
« on: April 06, 2021, 02:01:22 PM »
I am working with a customer who is looking for the following call flow:

Incoming Call>AA>ACD Huntgroup with 2 agents
                              |----If no agents are logged in, immediately recall to a 2nd UCD hunt group
                              |----If there are agents logged in, but busy, camp-on for up to 3 minutes then recall to the 2nd UCD hunt group.

Right now, my biggest hang-up is the fact that the caller camps on to the ACD group for 3 minutes regardless of whether there are agents logged in or not.

Does anyone have any creative ways to program this?

Thank you,
Adam

7
Ensure that your MiCollab client deployment profile has a valid resolvable server defined in the "Config download host" field.  This should be your MiCollab server.  *See attachment

8
Under MiCollab client configuration, you should have a checkbox under Default Account Settings
*See attached image

9
Are you using an MBG to proxy the MiCollab client traffic from outside the LAN?

10
Mitel Software Applications / Re: MiCollab Microsoft Office 365 OAuth 2.0
« on: December 04, 2020, 03:19:41 PM »
It appears after I re-authenticated with good credentials under the Standard connector and then switched back to OAuth and saved again, the test was successful.   The most insightful information I guess I would have is to use the Office 365 Exchange Online permission in the Azure application configuration permissions instead of Exchange under supported legacy apps as the documentation describes.

11
Mitel Software Applications / Re: MiCollab Microsoft Office 365 OAuth 2.0
« on: December 04, 2020, 09:00:46 AM »
I was able to get this functioning.... Thank you

12
Mitel Software Applications / MiCollab Microsoft Office 365 OAuth 2.0
« on: December 01, 2020, 06:05:57 PM »
Greetings,

Has anyone here successfully configured OAuth 2.0 to Office 365/Azure AD? 

I've attempted to follow the online help guidance which is scant at best and the only part that is not clearly defined are the permissions needed on the Application registration.  The online help dictates this:

  • To use OAuth 2.0, an application must have an application ID issued by Azure Active Directory. On the Request API page, select Exchange under Supported Legacy APIs followed by Application Permissions and then select full_access_as_app. Then click Add Permissions.

The problem I encountered is that I only have Microsoft Graph available under Legacy APIs.  The closest thing I could find is "Office 365 Exchange Online" under APIs my organization uses which does have the full_access_as_app permission.  I've enabled this permission and configured everything else as described.  The trouble I am having is when I click test in the Calendar Integration section when OAuth 2.0 is configured, regardless of what Username I enter, it fails with a Invalid calendar server credentials.: Invalid credentials. message. 

Any ideas or should I reach out to support?

Thanks,
Adam

13
Mitel Software Applications / Re: MSL - Session timeout
« on: June 11, 2020, 12:27:34 PM »
Anyone?

14
Mitel Software Applications / MSL - Session timeout
« on: May 27, 2020, 10:08:52 AM »
Is it just me or is there no way to timeout a login session on MSL / Server manager?   

15
Mitel MiVoice Business/MCD/3300 / Cluster transfer / re-routing issue
« on: March 28, 2020, 10:31:16 AM »
Hello all,

We are currently working to find a solution to an issue in a clustered environment where calls present into a SIP trunk on a MiVB 9.0 controller, pass through Nupoint call director AA, and are ultimately answered by an attendant station pinned to another cluster member and then are transferred to a stations pinned to either the same or another cluster member.  We have certain stations that are using business schedules to apply call rerouting rules to reroute calls originating from DID and CO to voicemail during daytime hours but allowing TIE and Internal calls.    Our goal is to make it so that direct outside calls cannot be made to these DNs during daytime hours, but transfers of outside callers from an attendant would be allowed.   We are relying on the COS option "Use Held Party Device for Call Re-routing" being set to "No" in order to allow this to happen with our rerouting rule.  It works great if both the attendant and receiving DN are registered to the same controller, but if the call is being transferred to stations with different primary controllers, the call rerouting rule applies regardless of the COS option being set to no.  We've tried setting the "Use Held Party device for call re-routing" option to "No" on COS 100 as we are using Direct IP vs XNET trunks.   We've also tried cutting NuPoint out of the equation and result is the same.   We had one suggestion to try this using XNET instead of Direct IP, but I'm hesitant to start making changes of that magnitude in production environment for testing.   I'm just wondering if anyone in the community has any insight on what the issue may be and how to fix it.

Thank you!
Adam

Pages: [1]