Messages

1

Mitel Software Applications / Re: Issues with Softphone on iPhone

« on: July 07, 2024, 05:12:44 PM »

You can check the wsp module to see what happens. Get into SSH and use a grep command on /opt/intertel/wsp.log

Also I think you already know that upgrading to 17.4+ will solve the issue.

Dutch

2

Mitel Software Applications / Re: IGNITE WEB V9

« on: July 07, 2024, 05:09:11 PM »

I am not sure if you can....

Ignite uses ElasticSearch to fill the fields. If someone knows if you can build in tenancy for that I am open to hear about it.

You can check on the MiCC when opening \Program Files (x86)\Mitel\MiContact Center\Support\ElasticSearchManager\ElasticSearchManager.exe

3

Mitel Software Applications / Re: Agent / ring group member question

« on: July 07, 2024, 05:05:48 PM »

Hello,

Can you see on the MiCC in the logs what agent/ring group member has taken a specific call?

Is there a way to now what member is next in line in a cascade circular ring group?

Or is there a way to get the index?

Regards

Jo

Only ACD shows individual stats. Ring grp only shows totals.

4

Mitel Software Applications / Re: Issue with MYCOLLAB 9.8.102 on Android 14: App Reconnects on Phone Lock

« on: July 07, 2024, 04:58:57 PM »

We have had months of contact with Mitel since januari especially concerning softphones during a big project.

The issues mostly were in the smartphone clients. I am sure we as a team (customer/us/mitel) had a big deal in the client going from 9.7.117 to 9.8.102 (103 for desktop) where it is now. I can only say the following:

Make sure ALL the clients are up-to-date!! This is not a choice!! iOS users we see update automatically whereas Android sometimes doesn't. You use Pixel. Make sure to Auto Update the client!

Thats a good start off and you will notice extensions remaining green. (it all has to do with push notifications and MBGs/MiVBs acting correctly in combination the the MiCollab. Not going into details but aside that for the latest MiVB version the MiVB will ignore people being offline for extended periods and the MiVB/MBG will still accept invites. Together with the new FCM API update this should resolve a lot.

You mention Pixel Phones which are Android. We see that Android (occasionally) is slower then Apple notifications but thats very scarcely and it can not be controlled. For UC endpoints this is fine. For ACD this could sometimes pose issues.

Basically the general idea now is make sure you have the latest MiVB. We currently use 9.7.110 for MiCollab and for us we only see issues sometimes with ACD. We set the No Answer Make Busy timer to 60 seconds in the COS to circumvent status changes due to delayed push. This kinda resolved the issue. UC Endpoints are fine but in case a push notification has a big delay and IF the user is working on a smartphone they will still receive the call assuming they have a good internet connection.

In the end its simple. If people have a phone job make them use the desktop client. Problem solved. Simple. Normal users with non-customer contacts eg non-acd will be fine.

As for the phones the new client will also ask for extra permissions during the first activation where the battery will want to be optimized. Unlimited will be the best solution as well as being able to have full access on the background and it circumvents deep sleep mode. Then you will see all is fine. We had the best experience with Samsung A5x as opposed to other Android devices. That said it can be situational. A good internet connection is key.

We have tested with phones being silent for a week and still got a good notification and ring on an Android phone.

In the deployment make sure you use TLS/SRTP Optional and port 5061. Use OPUS on the CODEC. You dont want to change the deployment profile with an active base. These settings work best since you deviate control to the MBG with the Optional Setting.

In the MBG make sure to use the SRTP or RTP setting for inbound. It will enforce SRTP when possible but it will allow RTP when applicable. Always use AVG+Crypto for outbound in combination with and 80 SHA1.

If you encounter issues you can now set a per user to RTP and avoid the encryption on traces so you can troubleshoot. All other users will remain to be encrypted. And for the test users you can analyse the traces and use them on tickets.

Long explanation. I hope it helps and I hope it doesnt come accross as too chaotic.

Cheers,

Dutch

5

Mitel MiVoice Business/MCD/3300 / Re: MXe-III performance improvement

« on: July 07, 2024, 04:24:31 PM »

The only reason there's analogue connectivity is due to back-compatibility with outdated systems (none physically present atm). Each hardware piece in our communication chain supports at least SIP, so that answers that. However, much like in every other large business machine, change is not always welcome, particularly if it involves expenditure of monetary resources.

Appreciate your response.

I would make a global inventory and categorize on modem or non-modem analogue devices. If modem I would investigate wether they need to be as opposed to different solutions. That said in NL the use of modem devices at the moment is a thing of the past (10+ years ago with building management servers and stuff which I had to deal with which were connected to a physical Gateway).

That remains Fax/Analogue Phone devices. You could always plan a small project to migrate them to SIP. Not sure if there is any Cloud or IP-VPN situations where local devices need to connect to cloud, but even if this is the case and if there is many analogues you could for example go with an Audiocodes or a different solution connecting the analogue devices and even get some marginal resiliency connecting them to virtual MiVBs.

In my experience if you put in some time you might find out that you should be fine ditching the physical single point of failure gateways (hardware yikes) and migrate to a more robust centralized situation.

Change is hard for many. Start small and show it works and create some base of support. It might just sell itself. In current times I you don't want to be dependant on possible non-resilient hardware that can fail with non-resilient analogue stuff.

These days its not hard to migrate to SIP on a per port basis and in the end remotely phase out the physical Network elements.

My 2 cents and I hope the above is a bit the answer you were looking for.

6

Mitel MiVoice Business/MCD/3300 / Re: ACD Logins without PIN

« on: July 07, 2024, 04:08:38 PM »

For me this goes back ages since I haven't used traditional ACD for over a decade, but could it be the agent ID is not a Hotdesk ACD but a traditional ACD agent? Afaik I can't imagine a hotdesk ACD not asking for a pin since the pin requirement is kinda baked in.

iirc traditional ACD doesn't need a pin. In the MiVB under Users and Devices > ACD > ACD Agent IDs you can see a column called Agent Type.

If it is something else I am very interested in how a hotdesk ACD is not asking for a pin since both a phone and Ignite will ask for a pin if its a hotdesk ACD but then again I am always open for being wrong.

7

Mitel MiVoice Business/MCD/3300 / Re: MXe-III performance improvement

« on: June 20, 2024, 02:07:58 PM »

Thanks for pitching in. My primary problem with MXe-III is overall response. Like, anything that I do through a web interface, be it accessing Users and Devices, or exporting a form, or generating a backup, you name it, it takes what subjectively forever in comparison with two virtual nodes in the system. And this is the same with both of my MXe's. Unfortunately I do have to keep them, as they're sort of acting like a gateway to satellite telephones, which currently require a plain analogue connection. In the future I guess none of that stuff will be needed, but who's gonna wait until then.

Ok, good to know it already has a Gb LAN. So then there's no means in increasing processing power (other than virtualization)?

Back in the past the physical servers were ALWAYS slower then their VM counterparts. can not compare.

The only thing that could improve performance depending on the situation was increasing the memory and installing a second CPU board (going to a 1000+ user config)

Still can not compare to VM and Hyper-V deployments. I would suggest going to ATA converter for the phones wether a multiple port device or a single line. Then again why do they need to be analogue and is there maybe another way to circumvent single point of failure situations due to analogue devices.

8

Mitel MiVoice Business/MCD/3300 / Re: Micollab audio issues with IVR

« on: June 20, 2024, 02:00:18 PM »

couple of stuff to setup:

1. COS IVR / Trunk > Make sure you set the following options
Music on hold on transfer = YES
Use local music on hold = YES

2. SIP Peer
w/e the provider sheet mentions and people say just ignore them when you use an MICC with IVR and set the following option (MICC IVR is never part of Interop testing or only briefly as far as I know)
Suppress Use of SDP Inactive Media Streams = YES (force sendrcv in SDP whenever possible)

3. IN the IVR in the WORFLOW as always use subroutines to efficiently handle memory usage and every item that starts a message try out the following:
Use a 2 second delay before the message starts.
(we have encountered situations where SDP and RE-Invites if SIP) where we need to give insert a delay to SDP negotiation to be effective before the message starts. We have encountered a per provider situation where messages would even result in NO Audio.

Whenever there is an IVR in combination with a MiVB with a SIP Peer you always need to make sure everything from the baseline works together. simple 1-on-1 calls is fine but when an IVR plays a message or transfers and you have audio issues the above probably will resolve. You mention hold and retrieve. The fact that makes a difference just triggered me to reply with the above.

Also if all else fails something you could test with is disabling PRACK. Not all calls/providers are efficient in using 180 or 183 and disabling PRACK in our country situations help .... SOMETIMES (only).

Just my 2 cents and I hope this helps, but anything can be situational. Worst case give me a pm if you need further assistance.

Dutch

9

Mitel MiVoice Business/MCD/3300 / Re: WS_xxxxxx.pcap in the /Vmail folder

« on: June 20, 2024, 01:47:49 PM »

Hi,

I think it works the same as it does for MiVB if not please please let me know. I just want to help out and go from there but I assume the setup is kinda the same approach.

Just make sure you use the correct IP for the MSL.

Login into "IP"/server-manager
Go to "Remote Access" and make sure you are allowed to use secure shell access (trusted networks only)
Go to Networks and make sure the subnet you connect from is in the trusted list and routable.

Then open WinSCP and login as for example root or another admin user you created.

Go to Root and on the bottom there is a /vmail folder with all kinds of goodies to play with.

Enjoy,

Dutch

10

Mitel Software Applications / Re: Mitel 5634 WiFi to Teleworker (MBG)

« on: November 15, 2023, 05:40:33 PM »

I usually test with manually entering the set and icp side passwords and make sure MiCollab gets entered setside first and mivb gets icpside last. Always works and is most secure. Templates from MiCollab...

11

Mitel Software Applications / Re: Teleworker TLS Version

« on: November 15, 2023, 05:34:35 PM »

if you don't put your MBG settings to "Intermediate" in the top the 53xx will never connect anyway which is TLS v1.2

The MBG in question I tested has all options of 1.0 and 1.1 de-activated by default.

Also as above poster mentioned you need to check the security settings in MiVB as well. Keeping all to High should I think be fine for 53xx phones meaning 5330 5340 etc but 5312 phones need a lower setting.....

12

Mitel Software Applications / Re: Mitel Soft Client

« on: November 15, 2023, 05:30:40 PM »

If you use UC Endpoint with TLS on deployment Mandatory and you put security to the highest in MBG settings you should be fine.

I did had to exclude specific outdated Cipher Suites but there is an SO article on that where you use exclamation marks on the webserver.

When you are ready you can always do a pen test on the URL and make sure the js libraries are updated and you should generally be fine.

I did find out that when using templates in MiCollab the setside password is identical to the ICP side when provisioned so worst case you could always do a manual import on MBG with different setside and icpside in combination with an MiVB import.

13

Mitel Software Applications / Re: Active Directory Integration and wants external dialing to contacts sync'd

« on: November 15, 2023, 05:24:33 PM »

Hi There,

Trying to split your items from the config but you mention MiVB,MiCollab,Ignite (the latter is ***Censored*** since it still works with elasticsearch and not the MiCollab phonebook). So....

If you use a MiCollab,
If you use a MiVB,
If you use MiCollab Clients,

then there might be a solution. Create an extra IDS (if need be I use Cloudlink Provisioning and SAML in combination with on-prem for External Search) connecting to the on-premise AD. Most is Azure these days but most are also hybrid. If you can connect to on-prem there might be a solution.

Just make an IDS entry without sync and auth to on-prem. Go to the bottom and check External Search (REMEMBER you need to enable External Search in the MiCollab Client Service Enterprise page too).

Define the search Base which is your Base OU and then define the mapping for Extension or Mobile to the correct mapping.

In my situations I use this connection to always look for users without an INTERNAL phone BUT with MOBILE and it must be an ACTIVE user. This translates to the following for example:
&(|(ObjectClass=user)(ObjectClass=contact))(UserAccountControl=512)(mobile=06*)(!(extensionAttribute9=*))

I look for and USER and CONTACT with Mobile filled correctly AND WITHOUT internal number AND is ACTIVE user.

If the search context is correct (you can use multiple OUs separated by ; then you can look on the TAB External in the Client. If you modify correctly incoming calls to the field of mobile in this case you also see the name on incoming calls when people call from their cells.

I just personally found out Mitel isn't too good with + and E.164. It just ignores it so ADs filled with cells that use E.164 you might need to adjust them to the numbering plan of your region.

Hope this helps a bit.

Cheers and good luck

14

Mitel Software Applications / Re: MiVoice Business Console 9.2 Setup

« on: November 15, 2023, 05:11:45 PM »

Something that may help but not sure. If you become a Mitel User Group member can you not download specific software yourself from the Mitel website?

We have a customer who mentions they can themselves download the software being an "enduser" being a MUG member. Maybe I am wrong.

15

Mitel MiVoice Business/MCD/3300 / Re: IVR Port not passing CLI

« on: November 15, 2023, 05:06:20 PM »

Also make sure your SIP Peer has the following options active. They might help here too:

Public Calling Party Number Passthrough = YES
Use Original Calling Party Number If Available = YES

Also make sure your Trunk COS has those options set from the get go since some options if they are blocked on the trunk you can not "enable" them later on. The below settings I tested and show the A-Number on the C-Party side so maybe check those settings on the "Display" part of the COS for the IVR Ports.

Good luck

After Answer Display Time   
Calling Name Display - Internal - ONS   Yes
Calling Number Display - Internal - ONS   Yes
Display ANI/DNIS/ISDN Calling/Called Number   Yes
Display ANI/ISDN Calling Number Only   Yes
Display Caller ID on multicall/keylines   Yes
Display Caller ID On Multicall/Keylines Timer   5
Display Caller ID On Single Line Displays For Forwarded Calls   Yes
Display Dialed Digits during Outgoing Calls   No
Display DNIS/Called Number Before Digit Modification   No
Display DNIS on Key Label   Yes
Display Held Call ID on Transfer   Yes
Display Transfer Destination on Recall   Yes
Hot Desk External User - Display Internal Calling ID   No
Maintain Ringing Party During Recall   No
Non-Prime Public Network Identity   No
Originator's Display Update In Call Forwarding/Rerouting   No
Prefer Call Forwarding/Rerouting Information   Yes
Prefer Name for Call Information   No
Suppress Delivery of Caller ID Display between Sets   No
Suppress Delivery of Caller ID Display between Sets - Override   No
Suppress Display Of Account Code Numbers   No
Suppress Redial Display   No