I know this is the way that vMix call functions at present, but is it good?

We have two vMix call inputs that we use for multiple guests on multiple shows, but it's unnerving to have what happened today happen - the guest for the next hour connected early and kicked a live guest off.

Yes, managing talent is one solution, but in our case they are not TV nor technical people, so they will always be prone to error.

I would much rather callers get a "Channel is busy, try again later" message when they attempt to connect with an already active login so we can protect our on-air product. Or better yet, have it say "Connection busy, waiting for previous call to conclude" then retry every 15-30 seconds.

I will have to read into the WebRTC protocol, but I have to say I have my doubts that there is no way to block subsequent calls using the same ID/password as an established call. The server in the middle (at vMixCall.com) is responsible for looking at the ID, mapping it to a listening vMix session input, and negotiating the WebRTC handshake / protocols that the ends will use. I'm pretty sure there are multiple steps during this process handled outside of the API (in StudioCoast code) during the call progress - read multiple places to block the call progress.

Again, I could be wrong. I will read up more on WebRTC.

That's fine. I guess if we want guest hits that can't be interrupted while on the air we'll have to do them via other stream/input types or assign new passwords every use. Having a live guest suddenly replaced by someone connecting a minute or two early is horrendous.

I'll add - be careful with the "it won't make money, so we won't do it" litmus test. I fully understand that coding time and resources are limited, and a company exists to make money. And in this case the benefit may not be in my favor, but if something saves headaches and adds to the overall utility and feeling of being a "well thought out, my bases are covered, no surprises" product, that it should at least be in the bottom of the priority list.

My idea for a liveshow would be: throw a few links in the comments and let the viewers get into the show. But when they can kick each other out, that will be a problem for sure.

I would love to see the possibility to 'lock' someone, after a login. Or would there be another solution for this?

Closing all browser windows that are using that password, and logging in again from a new browser window will recover the call.
This is actually by design, as browsers and internet connections can fail, and maybe the guest wants to move over to a mobile phone to connect at a moment's notice, for just one example.

Finally, it is not possible practically speaking to randomly type in a password and knock some person off a call, the chances are extremely low for that to occur.
(There are billions of potential call passwords, all randomly generated)

I'm not 100% on the issue with webRTC, but my guess is that it can't tell what connection it's supposed to be using, the first or the second.

I'm wondering if an easy way to fix this is to have a "password" to allow access to the specific vMix application, and also a connection ID that is assigned at the point of connection which is randomly generated each time someone logs in. The connection ID identifies the individual and would allow you to reload the browser in case of a disconnection. A new login though would generate a new connection ID and if the ID doesn't match the current running connection ID it rejects it.

There would need to be some way to clear the current running ID though otherwise it would only run once and then block all further connections. Maybe a button in the call manager along with a timeout.

@ Rafael Gil M

Unfortunately, I disagree, this is not an urgent issue or one that needs to be resolved.
It is highly unlikely that this “behaviour” will ever be changed.
VMix Call passwords are private and should be treated as such, there is no reason for anyone else other than the person you want to talk to to have it.
Putting restrictions or “locks” onto a call password potentially causes more issues than it solves.
As it is now, it makes “reconnecting” for the caller issue very easy in the event of a network disruption (which is a lot more common than someone calling in uninvited.

Just my thoughts.



Ice

That is only possible if someone connected using a Call Password they already had access to.
So if you want to prevent this from happening make sure to use a new Call Password each time, go to Input Settings -> Change and replace
the input with a new call password that way.

Note this is not a security issue, as the password numbers are too large to be guessed accidentally.

This is not an urgent issue. The problem is that we cannot use these passwords like phone numbers. There are easy ways to generate new passwords and it would seem extremely obvious best practice to generate new codes per guest/show.

Is it totally secure? No. I dont want it to be. The most important feature of vMix Call is its extremely low burden of knowledge on the Caller. I dont want some MI6 level authorization process, proprietary separate application and so forth. I want a browser based click and connect.

If you really need this, consider buying a NewTek Skype hardware device ($$$$$) or a Cisco VTC hardware codec ($$$$$), or ship the Remote Guest an HD broadcast cam w Teredek Cube ($$$$$$$), or look into using Quicklink's service (great service, hardware is $$$$$$$).

You could also set up a stack of Mac Minis each running Zoom pinned fullscreen and outputting NDI ($$$$$$$$)

Give Ross video a call. Getting a remote video call system with HD switching, great SRT implementation built in CG for lowers and so forth should cost well over a $100k. This is a steal. Realize what you have and work around extremely minor oddities.