Testing MimoCall - Only connects in DMZ

Hello,
In the process of testing a MimoLive configuration using a MimoCall layer.
The MimoCall connection will connect via the internal network, but will not connect to a remote caller, via the Internet.
If the MimoLive machine is placed in the DMZ, of the router, the MimoCall will connect.

Any ideas, or thoughts, on what needs to be changed on the router to allow MimoCall to work without having to place the MimoLive machine in the DMZ??

Thank you for your input and assistance.

Update -
During additional testing I was able to get the call to connect, without placing the machine IP in the DMZ. I had to forward some ports (a massive range).
I forwarded 8000:65535, which worked.
I’m wondering, now, if that range can be minimized somehow. Thoughts?

@rwildman Thanks for using mimoLive.

We’ll have to investigate this behavior because clearly that’s not how it should work.

Meanwhile, you could try to enable uPnP on the router. If you do, please let me know if it worked.

Thanks for your patience and cooperation!

Hello Oliver,
UPnP is enabled on the router. But without forwarding the ports, there is no joy in Mudville.
I’ve been able to narrow the range of ports to 60000:62000, with moderate success. To successfully connect one may have to “reconnect to Remote peer” once or twice.

The router in use is an Asus RT-AC3200. I hope that can be helpful to you.

Looking at port notification data, I do not believe it would be prudent, or secure, to leave the above mentioned ports open at all times. I sincerely hope that your team can find a solution to this issue.
However, I suspect that it may be Asus who is at fault, even though I’ve never had problems with WebRTC connections before.

One additional item of note.
When attempting to make the MimoCall connection without the ports being open, even though the audio and video connection is not made and the remote client indicates no connection, when, on the MimoLive end, clicking the “Reconnect to Remote Peer” the MimoCall client background does flicker (i.e., change color as though it is receiving something).

Hi, this is Stefan from engineering.
Thanks for reporting your issues, this might very well be the first time we hear about port-related problems with mimoCall.

For establishing a connection between mimoCall partners, three different steps/techniques are involved:

  1. Signalling: This happens via HTTPS/WSS on port 443 with a server operated by us. This step obviously works, since you are able to create and join a mimoCall channel from mimoLive.

  2. Public IP Discovery (STUN): Both participants have to figure out their public IP addresses in order to exchange information about how to contact each other. This is done using the STUN protocol. We use Twillio’s STUN server which uses UDP/3478, so make sure that outgoing connections to that port using UDP are allowed in your router.

  3. Server-side Relay (TURN): If no direct connection between both participants can be established (because one of the routers’ NAT settings prevents it), data is relayed using a server on the Internet. In our case, this service is again provided by Twillio. As of now, multiple ways of reaching the TURN servers are provided by Twillio:
    UDP/3478, TCP/3478 and TCP/443.
    Especially because of the last option, compatibility should generally be really good and I can’t find a sound explanation of why you’re experiencing problems that are partially solved by forwarding ports in the 6xxxx range.

However: We have recently upgraded the mimoCall web client to use a more standard-compliant version of the WebRTC protocol. Even though we tested the changes against mimoLive 4.7, it might be possible that you have greater success when using mimoLive 4.8b1 (which is generally very stable, we just release it as beta because of the new features it contains which have not been tested as long as the rest of the application).
So please try again with mimoLive 4.8b1 and report back if that works better.

Best,
Stefan

Hello @Stefan,

I appreciate your thoughts on this issue.
My apologies for not getting to this sooner. I’ve been a bit under the weather over the last couple of days.

I’ve opened the suggested ports, after closing the ones that were previously open. Please see the attached pic.
(https://drive.google.com/open?id=1qTds4fcxyIoObVISh_UDG4IIRnrFBTSf)

I’ve also created a short video of the situation. The video depicts the pertinent area of the MimoLive screen (specifically the mimoCall information area) and the mimoCall client, in this case an Android phone. You will be able to see both the phone’s and MimoLive’s responses/reactions to the connection process.

MimoCall Video Clip

Needless to say, since I’ve gone through the process of attaching all this material, simply, opening the suggested ports did not resolve the issue. I should, also, mention that working with the Beta version, with these same settings produced the same results.

Thanks for your feedback and sorry for the inconvenience caused.

We have identified an issue in the web client that prevented step 3 of my previous answer from functioning correctly.
This is why the connection worked locally and with open ports but not when the relay service was required.

An updated version of the web client has been deployed, please try again to verify that your problem has been solved.

Best,
Stefan

@“Stefan (Boinx)”
Well done. I can confirm that the call now connects.

You’ve saved me from having to begin testing a Wirecast solution.

@“Stefan (Boinx)” @“Oliver (Boinx)”
One thing of note: While the call connects and video passes, no audio can be heard from the caller by the host.

Thoughts?

@rwildman do you have a dedicated Audio Only layer for the mimoCall caller? Some Layers include audio and some don’t. Layers with multiple audio sources can’t have audio and require a separate layer for the audio.

@“Oliver (Boinx)” @“Stefan (Boinx)”
I’ve created multiple iterations of the template. I have had an Audio Only layer for the mimoCall.
The funny thing is that the audio could be seen in the level meters, but not heard. While all other audio from the system was heard.

I would like to put together a video to better show and explain the issue. However, doing so isn’t as easy as one would hope, due to camera angles and resolution. Being able to read any text, in the resulting video, is difficult at best.
I would, however, be willing to explore other options in order to help your team run down this issue and find a solution.

On an aside note, I’ve been experiencing the application abruptly crashing when removing output destinations.

@rwildman Thanks for your patience and for not giving up! I appreciate the offer to work with us on resolving the issue.

As a first step, can you please send me the document? (Send me a link to a dropbox download or something like that by direct message in this forum)

If I can’t find anything, we can set up a TeamViewer session to have a look at your computer next week.

It would also be helpful to get the crash logs. (https://docs.mimo.live/docs/crash-reports)

I believe I’ve found the problem with the ‘output destinations’ crashing. It looks like it was a corruption in the YouTube destination entry.

I will, however, get a copy of the document to you.

@rwildman Thanks for the update. Even if you found the issue and are able to work without crashes, please send the crash logs.

@“Oliver (Boinx)”
Thank you for the email. Crash report sent to you.

Important item of note (mostly to self) - Make sure that one is reminded to turn the audio mix ON.

Pleased to state that I was able to conduct a successful test of mimoCall today.
Thank you both, @“Stefan (Boinx)” and @“Oliver (Boinx)” .