Catching "disallow" in webcam/mic dialog of the browser

Hi! I want a user to be able to participate in a session although he denied the access to his webcam (but not the microphone). Instead of his webcam stream I want to implement some kind of placeholder, so others can see some incognito user is onboard. How can I achieve this? I already found a hint in another thread mentioning the “accessAllowed/accessDenied” events on the Publisher object. But I don´t know how to implement it so it fits my need.

Any help is highly appreciated!

Thx and regards, Martin

You just have to place in the HTML whatever element or placeholder you want upon the “connectionCreated” (if not publishing) or “streamCreated” (if publishing audio) event for this user, in every other user connected to the session. The “accessAllowed/accessDenied” event will only inform the local user that it has or has not access to the requsted device. But you can of course join any user to the session without publishing, or publishing only audio. You have total freedom.

Ah, of course, yes! I understand. Thx for the reply!

I have to open this again.

Meanwhile I have played a bit with “connectionCreated” and “streamCreated”:
“connectionCreated” fires BEFORE the user has made the decision either to allow or to deny his webcam usage.
“streamCreated” ONLY fires when the user has allowed the webcam.

Using both of this events I would´ve to create a placeholder for every connection and then had to replace the placeholder with the stream, if any.
Actually what I would require is an event like “streamDenied” in which I could react with a placeholder for a subscriber that denied his webcam.

How could I achieve what I need if “streamDenied” doesn´t exist?

I don’t understand the problem you have with the timing between connectionCreated and streamCreated events.

Both of them are very different events: connectionCreated means that the user is connected to the session. He can start receiving/sending signals, getting other session events, publishing video…

streamCreated event for the Publisher object means that the user has successfully published a Publisher object to the session. This can only be triggered after calling Session.connect and Session.publish methods. This means that other users connected to the session will have received a streamCreated event for this Publisher object (a remote stream from their persepective).

Do you see the relationship (more like the lack of it) between these two events? The only thing you can be sure about is that any streamCreated event will be fired after receiving connectionCreated event. And that the streamCreated event for a local Publisher object will only be received after calling Session.publish.

You are receiving the connectionCreated event before the user has made the decision either to allow or to deny his webcam usage because that is perfectly possible. You are calling Session.connect, that is successful, then you are calling OpenVidu.initPublisher, and that is the method asking for permission. If the user denies it, he will receive accessDenied event. As docs state:

The Publisher object will dispatch an accessAllowed or accessDenied event once it has been granted access to the requested input devices or not.

Where is the problem? Why do you need a different streamDenied event? Why are you talking about a placeholder?

Hi Pablo! Thx for returning to me. The way you explain the events, I understood it and used it. I think I need to describe my use-case a little more precisely:

I want every participant to be visible in every other participant’s session, regardless of whether they shared their webcam or not. In the event that a participant refuses to share his webcam, a placeholder should symbolize his passive participation in the conference. Whether a placeholder or the stream is displayed, I have to implement two different ways:

  1. For the participant’s local session (using accessDenied on the publisher object)
  2. For all participants who join the conference (this is where I´m missing an event)

The first case was easily done. But the second case gave me a headache. I would like to see an event here. But it has now occurred to me that I can implement the event myself using the handy signal method on the session :slight_smile:. I have not yet implemented it, but it should do the trick.

I can imagine that my request is rather unusual: Why would someone refuse their webcam when participating in a video conference? But in my case you might be forced to take part. And I would like to enable these people to participate passively.

Maybe I could make it a little easier to understand. I think I found a solution. If you can think of something better, always let me know.

Thx and regards :slight_smile: ,
Martin

Of course, that is the way to go. Signals are available precisely for this kind of usages. There is no reason to implement a standalone official event “streamDenied” or something like that. Because we would have an infinite amount of events. What if a user does not have a microphone? Is that enough to send a different event to the rest of participants? Of course not. But if it is relevant in your use case, just send a broadcast signal when required. That applies to any situation not contemplated by the official standalone events.

Cheers.