Closed edushare closed 6 years ago
Hi @edushare, are you using MCU key?
Also just a check, are you referencing the https://github.com/Temasys/getaroom demo?
no, do not think my key is MCU enabled.
Did not use getaroom as reference, as my application is , some one join the room and only have video link with host only. all the other people did not build video link to each other. (they skip the welcome message and skip handshake process) but now, they even can not send message to each other, this never happen before, seems only happen in last few days Is there any change on Sig Server side?
Hi @edushare, do you happen to be using the privileged key scheme? Also if you have a demo link we can test and try and investigate what's the issue more?
There has been no recent changes on the signalling server.
no, the key is very old , used for more than one year.
the issue is not there 2 weeks ago I think. not exactly remember.
The public message is not send to all user in the room , this is the issue. It is confirmed problem.
Hi @edushare, which version of the SDK are you using?
In regards to "(they skip the welcome message and skip handshake process"
, it shouldn't happen since it will always establish a PeerConnection so hence the handshakeProgress
will always be processed even if the user has no media sending and receiving.
Based on your use-case, I suggest that you use the privileged key scheme which might aid a lot for your case. You can turn off Auto Introduce for both the customer and agent alias key and Privileged turned on for the agent alias key in the Room. To retrieve all the Rooms and its users in the parent Application Key space, you can use getPeers()
. To start connection with a selected Peer or to introduce a Peer to another Peer, use the introducePeer()
method.
Your suggestion will not work in my use case, We have 2 type of role in the conferencing, teacher and student. teacher should able to see each student's video , but student should not see each other.
Base on the current design, each student can only have one type of video/audio status, so, still come back to the same problem. if 2 user finish the handshaking process, they will setup video link which in most of the case is not right.
that is the reason we break the handshaking process.
Public message should be forward to all the user . This is a very simple requirement I think, but somehow, it is not working.
Close issue
Seems the message is not broadcast to all user unless they have video connection(handshaking process finished)
The change seems happened on Server side, any particular reason for this?