logo

Live Production Software Forums


Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

2 Pages12>
Options
Go to last post Go to first unread
TBacker  
#1 Posted : Saturday, January 11, 2020 2:00:12 AM(UTC)
TBacker

Rank: Advanced Member

Groups: Registered
Joined: 10/29/2019(UTC)
Posts: 93
United States
Location: Syracuse

Thanks: 9 times
Was thanked: 4 time(s) in 3 post(s)
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.
mjgraves  
#2 Posted : Saturday, January 11, 2020 6:50:12 AM(UTC)
mjgraves

Rank: Advanced Member

Groups: Registered
Joined: 7/1/2015(UTC)
Posts: 1,150
Man
United States
Location: Houston TX

Thanks: 319 times
Was thanked: 263 time(s) in 233 post(s)
vMix Call is a WebRTC application. Much of its functionality a constrained by WebRTC as a platform. There is no way to implement what you suggest without a major amount of work to abandon the mechanics of WebRTC in the browser, and re-engineer the web service itself.

You're better off to upgrade your vMix license to support more vMix Call instances. My 4K license supports 2, pro supports 4. That way you can give separate access details to each of your guests.

I suppose you might have separate vMix Call instances for each of them preset in your project. Perhaps only the # allowed by your license would be allowed to connect.
TBacker  
#3 Posted : Saturday, January 11, 2020 8:30:48 AM(UTC)
TBacker

Rank: Advanced Member

Groups: Registered
Joined: 10/29/2019(UTC)
Posts: 93
United States
Location: Syracuse

Thanks: 9 times
Was thanked: 4 time(s) in 3 post(s)
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.

mjgraves  
#4 Posted : Tuesday, January 14, 2020 4:27:45 AM(UTC)
mjgraves

Rank: Advanced Member

Groups: Registered
Joined: 7/1/2015(UTC)
Posts: 1,150
Man
United States
Location: Houston TX

Thanks: 319 times
Was thanked: 263 time(s) in 233 post(s)
Martin & the team stood up the service quickly, and for free, buy leveraging a reference implementation of a webRTC video chat service.
That reference implementation does not have the capability you describe.

It could be implemented, but it would require significant effort for little advantage, and for zero additional revenue.
TBacker  
#5 Posted : Tuesday, January 14, 2020 4:45:24 AM(UTC)
TBacker

Rank: Advanced Member

Groups: Registered
Joined: 10/29/2019(UTC)
Posts: 93
United States
Location: Syracuse

Thanks: 9 times
Was thanked: 4 time(s) in 3 post(s)
Originally Posted by: mjgraves Go to Quoted Post
Martin & the team stood up the service quickly, and for free, buy leveraging a reference implementation of a webRTC video chat service.
That reference implementation does not have the capability you describe.

It could be implemented, but it would require significant effort for little advantage, and for zero additional revenue.


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.
Barney Box Lane  
#6 Posted : Monday, January 20, 2020 2:10:45 AM(UTC)
Barney Box Lane

Rank: Advanced Member

Groups: Registered
Joined: 8/21/2017(UTC)
Posts: 314
Location: Uk

Thanks: 25 times
Was thanked: 33 time(s) in 29 post(s)
If its important and worth it then they do offer more callers in the 4k/pro version where you can add up to 8 with their own passwords
thanks 2 users thanked Barney Box Lane for this useful post.
sinc747 on 1/21/2020(UTC), mjgraves on 1/21/2020(UTC)
Bunkerboss  
#7 Posted : Friday, February 14, 2020 8:31:44 PM(UTC)
Bunkerboss

Rank: Member

Groups: Registered
Joined: 2/14/2020(UTC)
Posts: 11
Netherlands
Location: Leiden

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?
grantcoll  
#8 Posted : Sunday, March 22, 2020 6:48:17 AM(UTC)
grantcoll

Rank: Advanced Member

Groups: Registered
Joined: 10/7/2017(UTC)
Posts: 94
Location: Hamilton

Thanks: 21 times
Was thanked: 10 time(s) in 9 post(s)
My experience with this shows the following:
One guest connected and talking.
A second guest joins in, typing his own name, but mistyping the password, I typed the same password as the first guest. This freezes both, and at vmix, both call inputs become named the second name, and both are frozen. This is no way to recover, as the calls can't be reset at that end. Even closing the offending ( 2nd call ), the first is still frozen.

This is a risk, as someone could type in a different password by mistake, and take out another clients show.
admin  
#9 Posted : Sunday, March 22, 2020 12:45:07 PM(UTC)
admin

Rank: Administration

Groups: Administrators
Joined: 1/13/2010(UTC)
Posts: 5,137
Man
Location: Gold Coast, Australia

Was thanked: 4135 time(s) in 1487 post(s)
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)
Rafael Gil M  
#10 Posted : Monday, July 20, 2020 8:01:58 AM(UTC)
Rafael Gil M

Rank: Newbie

Groups: Registered
Joined: 7/20/2020(UTC)
Posts: 3
Dominican Republic
Location: Santo Domingo

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
This topic is very important and above all for security. I agree with previous posts that there must be a solution, or VIMIX must seek a solution and I think it is urgent. Because not only because of the shame that happens at that moment when a person enters a video call unrelated to the subject that is being discussed in a live broadcast, there are many other security factors. Because the guests are not technical and the second to enter the video call does not know that this code is busy, we could have 4 different codes for the same number of people, who are going to connect at different times, but those guests can be wrong about time and enter the moment that does not correspond in the show. Please urgent solution. Thanks
thanks 1 user thanked Rafael Gil M for this useful post.
Chrispy on 6/15/2022(UTC)
cgibson  
#11 Posted : Monday, July 20, 2020 8:40:45 PM(UTC)
cgibson

Rank: Newbie

Groups: Registered
Joined: 7/20/2020(UTC)
Posts: 3
Australia
Location: Brisbane

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  
#12 Posted : Wednesday, July 22, 2020 1:36:04 AM(UTC)
Rafael Gil M

Rank: Newbie

Groups: Registered
Joined: 7/20/2020(UTC)
Posts: 3
Dominican Republic
Location: Santo Domingo

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Originally Posted by: cgibson Go to Quoted Post
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.


I do not have total mastery of the subject, but I suggest some urgent solution, perhaps at the software level. A button to allow or not connections. First maybe the software will generate a warning, example: there is a new connection, do you accept it? yes / no AND the VMix user decides whether to accept it or not. But there must be an urgent solution


thanks 1 user thanked Rafael Gil M for this useful post.
Chrispy on 6/15/2022(UTC)
IceStream  
#13 Posted : Wednesday, July 22, 2020 4:02:56 AM(UTC)
IceStream

Rank: Advanced Member

Groups: Registered
Joined: 3/7/2012(UTC)
Posts: 2,600
Man
Location: Canada

Thanks: 33 times
Was thanked: 501 time(s) in 470 post(s)
@ 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
cgibson  
#14 Posted : Friday, July 24, 2020 8:41:34 PM(UTC)
cgibson

Rank: Newbie

Groups: Registered
Joined: 7/20/2020(UTC)
Posts: 3
Australia
Location: Brisbane

Originally Posted by: IceStream Go to Quoted Post
@ 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


The issue that I have with this setup is that the vMix operator has no control. Zoom got blasted for allowing "Zoom bombing", which was worsened when random strangers could jump into school classes. Technically the same thing could happen here. While there might be a high number of combinations with "passwords", it makes the "attack surface" a lot easier when it's just numbers you need to run through.

That's why I suggested a "password" to allow you to call vMix, but also a connection ID generated when you login to Vmix calls (20 random alpha numeric chars) which would allow you to reconnect without allowing hijacking.
Rafael Gil M  
#15 Posted : Saturday, July 25, 2020 2:14:26 AM(UTC)
Rafael Gil M

Rank: Newbie

Groups: Registered
Joined: 7/20/2020(UTC)
Posts: 3
Dominican Republic
Location: Santo Domingo

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Originally Posted by: cgibson Go to Quoted Post
Originally Posted by: IceStream Go to Quoted Post
@ 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


The issue that I have with this setup is that the vMix operator has no control. Zoom got blasted for allowing "Zoom bombing", which was worsened when random strangers could jump into school classes. Technically the same thing could happen here. While there might be a high number of combinations with "passwords", it makes the "attack surface" a lot easier when it's just numbers you need to run through.

That's why I suggested a "password" to allow you to call vMix, but also a connection ID generated when you login to Vmix calls (20 random alpha numeric chars) which would allow you to reconnect without allowing hijacking.


Hi. I continue to insist that it is very necessary to solve this problem both for security and for the fact that an embarrassing fact can happen in a television show or in an event broadcast. There must be a way to solve that problem, I suggested the option that from the VMix program and in a new update, it is included that the user with a button, can reject or admit an incoming video call

thanks 1 user thanked Rafael Gil M for this useful post.
Chrispy on 6/15/2022(UTC)
craigreilly  
#16 Posted : Tuesday, September 1, 2020 3:45:36 AM(UTC)
craigreilly

Rank: Member

Groups: Registered
Joined: 7/24/2020(UTC)
Posts: 12
United States
Location: AZ

Was thanked: 1 time(s) in 1 post(s)
Originally Posted by: admin Go to Quoted Post
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)


We got vMixBombed last week.
Middle of a presentation...

admin  
#17 Posted : Tuesday, September 1, 2020 1:19:03 PM(UTC)
admin

Rank: Administration

Groups: Administrators
Joined: 1/13/2010(UTC)
Posts: 5,137
Man
Location: Gold Coast, Australia

Was thanked: 4135 time(s) in 1487 post(s)
Originally Posted by: craigreilly Go to Quoted Post


We got vMixBombed last week.
Middle of a presentation...



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.
thanks 4 users thanked admin for this useful post.
doggy on 9/1/2020(UTC), eduardocfs on 9/1/2020(UTC), greggibson on 9/2/2020(UTC), elvis55 on 9/2/2020(UTC)
grantcoll  
#18 Posted : Wednesday, September 2, 2020 12:05:15 PM(UTC)
grantcoll

Rank: Advanced Member

Groups: Registered
Joined: 10/7/2017(UTC)
Posts: 94
Location: Hamilton

Thanks: 21 times
Was thanked: 10 time(s) in 9 post(s)
I have to continue to agree with others concerned about misuse of passwords. Even during testing, I have entered a wrong password, and immediately thought, I hope I didn't kick some other caller of a show somewhere in the world. I feel that there is no link between name and password when it reaches the vMix doing the live stream. You can type any name whatsoever, and it makes no difference to the password.

I would like to see at the incoming vMix end, when the input is created and the password is allocated, that you can type in a name or a range of names that will be valid names for the generated password. So, eg you create a vmixcall input and vmix generates the password. Then you type in names that will be used. When someone attempts to connect, WEBRTC routes the call to your vMix doing the Live Stream, and then vMix checks that the name is one of those valid for that input.

That would improve the security, and avoid mistaken connections.
thanks 1 user thanked grantcoll for this useful post.
Chrispy on 6/15/2022(UTC)
Button_masher  
#19 Posted : Monday, September 21, 2020 6:13:02 AM(UTC)
Button_masher

Rank: Newbie

Groups: Registered
Joined: 9/21/2020(UTC)
Posts: 1
United States
Location: East Coast

Thanks: 1 times
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.
mavik  
#20 Posted : Monday, September 21, 2020 5:21:53 PM(UTC)
mavik

Rank: Advanced Member

Groups: Registered
Joined: 4/23/2017(UTC)
Posts: 1,126
Man
Location: Germany

Thanks: 3 times
Was thanked: 164 time(s) in 146 post(s)
I would like to mention a solution that fits inbetween. Not for free (free testing available with watermark), and not for big money. Take a look at medialooks VT solution. You have the choice of webRTC or SRT, could roll out soe guest module software or even a partner license if you have frequent contributers.

And there is no 100% security. never, ever.
Users browsing this topic
2 Pages12>
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.