2021 – mimoCall crashes mimoLive immediately after caller joins

I know this topic is exactly the same as in previous topics from other users. They are from 2020.
Today, I don’t see how possible is to use mimoLive and mimoCall, since mimoLive keeps crashing at the very moment a user clicks and goes to the mimoCall link. And, after two or three attempts, the mimoLive template created for the scope becomes useless, because opening it will immediately let the Program crash.

mimoLive version Version 5.11 (I also tried with mimoLive 6.0b5 – a beta)
Mac OS 12.0.1 Monterey

Hardware (it may sound ridiculous, but it is what it is):
MacBook Pro (16-inch, 2019)
2,4 GHz 8-Core Intel Core i9
64 GB 2667 MHz DDR4
AMD Radeon Pro 5500M 8 GB
Intel UHD Graphics 630 1536 MB

Nothing else is in the way of this set-up (actually, it crashes BEFORE I can do or add anything else :slight_smile:

Many thanks for any suggestions and guidance.

1 Like

No, it does not sound ridiculous. Does it also crash, when you plug out all usb/thunderbolt peripherals? WebControlSurfaces is on?

Please have a look here, because of bug reports:


thanks for your reply and yes, it crashes “by default”.
Have a good one,


Well, it does not crash in my case, so… :wink:

  1. Did you send the bug report?
  2. Can you describe the WebControlPanel-situation?
  3. Which Version of mimoCall is in use?
  4. What other software is executed the same time? (Any RAM-optimizers?)

I could ask hundreds of more questions about this phenomenon. It’s a pity, without detailed descriptions on your side, no one’d be able to help.

Hi @marcello Sorry to hear about the troubles with mimoCall. This problem appeared in macOS 12.0.1 and should be fixed in mimoLive 6.0b5.

If it’s still crashing in 6.0b5 please send me the Crash Report that appears after the crash via DM (click on my icon and on “message”.)

I am having the same problem. Tried on the 6.0b5 beta version. I can’t message you directly for some reason but I have a crash report. Thanks. Jason

1 Like

I’ve been actively sending crash logs to tech support as mimoLive has been crashing this last week. And, after crashing, the doc won’t open if any browser anywhere has the mimoCall page active in a tab/group. Same behavior with mimoReporter. As soon as they kill page/app I can open mimoLive docs.

Then I conjectured it might be port related, so tech sent me the thread about ports and I opened TCP 443 and TCP/UDP 3478. port checker.co says the ports are closed, even though the firewall says open. As an alternate test, I have a remote security system that uses DDNS to tunnel back through my network/firewall to get to the security server software, and it works fine with no port forwarding. Still working with BD Box on ports.

mimoLive: 6.0b5
mimoCall: tried standard and beta
iMac 2019 i9 3.6 8 core, Radeon Pro Vega 48/8 64M Ram
Monterrey: 12.0.1
Modem: Spectrum eMta Docsis 3.1 400/20 (verified speed/latency)
Firewall: Bitdefender Box 2 set up as standalone router (they tell me in this mode there is no double NATing)

Hoping it can be debugged soon, had to pass on remote stream calls the last two test sessions and have another scheduled this week.

Any hints are welcome.


As @jasonwissinger said, it seems there’s no way to send you DMs. I have two crash reports now if you’re interested.
Many thanks.

Getting slightly frustrated here with crashing. I ripped the BD Box 2 out of the network and turned the Orbi RBR50 into the router, so there is just the Orbi and the eMTA cable modem (just modem, no router). I opened ports 443 and 3478 on the Orbi per other posts and port checker still says ports are closed. I then enabled UPnP and still no open ports. MimoLive still crashes as soon as a connection is made. Tried 2 different Macs with the laptop having very few apps installed on it. So then I ran MimoLive and did a port scan on the workstation. Here are the active ports, none of which are 443 or 3478…only the 8989 which is the server for mimoLive control pad. I’m wondering if 443/3478 ports are actually still used by mimoCall?
Ports -
88 KERBEROS-SEC;Kerberos (v5);;88
445 MICROSOFT-DS;SMB directly over IP;;445
3689 RENDEZVOUS;Rendezvous Zeroconf (used by Apple/iTunes);;3689
5000 UPNP/SYNOLOGY;Synology NAS;;5000
5900 VNC;Virtual Network Computer display 0;;5900
7000 AFS3-FILESERVER;file server itself, msdos;;7000
8989 ;;;8989
39957 ;;39957
49208 ;;49208
53034 ;;53034
59866 ;;59866
If anyone has ideas I’m ready!

I have more findings from testing

  1. I connected the Mac with mimoLive directly to the eMTA modem and ran in internal port scan against the Mac (from an iPad). I then took those ports and ran external portchecker.co and found:
    Port 88 is open.
    Port 3689 is open.
    Port 5000 is open.
    Port 5900 is open.
    Port 7000 is open.
    Port 8989 is open.
    But ports 443 and 3478 were not open
    This leads me to believe the ISP is not blocking all ports. However, I’ve read that some ISPs block 443 to keep people from setting up web servers. As a test I opened some of the ports from above (like 8989) on the Orbi and tried a port check from portchecker.co, which returned closed. That is leading me to believe the Orbi port forwarding may not be working.
    As a final test, I connected the Mac directly to the modem and mimoCall crashed mimoLive on connect, which leads me to think that maybe something else might be causing the problem, other than ports.

@junk1 @marcello @jasonwissinger My apologies for the long silence. Thank you everyone for sending the crash reports.

After a lot of digging, we have been able to confirm and reproduce this crash which is happening only on Monterey on some Intel machines. We think it might be a change in macOS that affects the Intel version of the WebRTC framework. We’re working on a fix.

Workaround for Monterey/Intel machines: Use mimoLive 5.8.1 for now.

Great news!