What I meant by the “user joining first is becoming the host” is that if I use role_type 1 for two participants (A and B), and If A is joining the session before B then isHost key for A will be true and it will be false for B.
But if B is joining the session before A then isHost key for B will be true and it will be false for A.
I got your point that, through Client.isManager() I can get to know which one is the manager.
but can I just set in a session that A will be the host and B will be the co-host (Manager), right now this depends on who is joining the session first.
The dependent assets are correct. I cannot make out the cause of the audio issue from the current messages, could you provide a demo that can be accessed publicly, so we can troubleshoot the issue?
I think you didn’t understand my query.
I asked a question that, can I make user A the host and B the co-host (Manager)?
Right now this depends on who is joining the session first.
Usually, the generation of JWT is done through the backend, so you can set the role_type in the backend service. It doesn’t conflict with your assumption.
That’s what we are doing right now, but we can’t call client.makeManger at the backend, right?
As I said, I am trying to make one participant a host and the second one a manager. but the thing is for both of them the role_type will be 1.
So from the backend, nothing can’t be done more than this.
After doing this, whoever will join the session first will become the host, and the second one will become the manager.
I don’t want this. If I am making a user ‘A’ a host then it should not depend on if A is joining before the manager(B) or not.
Even if A is joining after then B then A should be the Host and B should be the Manager.
Backend generates the JWT of A with role_type=1, and JWT of B with role_type=0, how to get it done? Usually, it depends on the credential, the backend service can identify the user.
Then the two users join the session, A now is the host, if he wants to make B the manager, or in your business logic, someone needs to be the manager, you can get the message from your backend service, and call the client.makeManager() to make it done.
We have tried so many workarounds for so many things, are we gonna have a permanent solution for this in the upcoming release?
You can make a new value for role_type like 2 for the manager role or something like that.
We don’t have a public environment for you to use. Can you try this on your end on iPad?
In this case, Other users are not able to hear the iPad user, and no errors are there on the console.
await startAudio({ speakerOnly: true });
// After some time
await mediaStream.stopAudio();
await mediaStream.startAudio();
Also, after the below statement runs, I have to click on the screen to start hearing other participants.
In this case, the user has already clicked once on a particular URL, so the issue is not that audioContext has not been initialized at that moment because the user has not interacted with the screen.
But with speaker-only functionality, why the click is mandatory?
I can understand if this restriction applies to the mic start functionality but also in this case, the user has clicked on the page before but just not when startAudio function call.
As I mentioned before that on our site the user has already interacted with the screen on the page where we are trying to play the audio with speakerOnly mode.
I have worked with Agora SDK as well, and there I didn’t face these kinds of issues.
I haven’t heard back from you in 5-6 days. When can I expect a reply regarding my queries?
I am facing one more issue in the Screen sharing, sometimes it is just getting stuck at a frame, and nothing is happening after that.
Even after stopping and starting it again doesn’t make a difference.
Please make some time for this and some previous queries at the earliest.
