I want to use smacks pluging with websocket. I configure prosody to be able to join anonymously but require token authentication for creating new room.
Smacks works great for autheticated users because these users reconnect with same xmpp identity.
However, if guest users try to resume, their identities are not the same as they used before. So Smack can not find correct session to resume. It returns that error…
<resume h=‘25’ previd=‘db78152f-fdf8-47db-b0b2-75d61fc9138f’ xmlns=‘urn:xmpp:sm:3’
Tried to resume non-existent session with id db78152f-fdf8-47db-b0b2-75d61fc9138f
Although there is no authentication at meet.jit.si, users keep their identity. How can I keep identity for guest users to use Smack Plugin properly.
Note: I use stable-5076 version with prosody-0.11.5. I already apply mod_websocket_smacks.patch and mod_websocket_session_event.patch
The username does not matter, what matters is previd id which is passed when resuming …
Maybe something is wrong with the logic when using anonymous domain, the same there was a bug when checking for enabled services and instead of the main domain was querying the guest one … this is my guess.
Can you try this? Use the token auth module, but set allow_empty_token to true. This is basically anonymous, but there is some extra code to match previd.
I faced with new problem about jvb websocket after resume. After i force to resume prosody websocket, I trigger colibri websocket to reestablished also. Sometimes i faced with these errors,
Client Side:
lib-jitsi-meet.min.js?v=420:17 WebSocket connection to ‘wss://meet.com/colibri-ws/jvb-m01-ins01/9d71074c099283d0/0f42bd80?pwd=angft2hueg0537bhniv7564cm’ iled: Error during WebSocket handshake: Unexpected response code: 403
_initWebSocket @ lib-jitsi-meet.min.js?v=420:17
t @ lib-jitsi-meet.min.js?v=420:17
lib-jitsi-meet.min.js?v=420:10 2021-02-25T08:28:41.116Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onclose>: Channel closed by server
lib-jitsi-meet.min.js?v=420:10 2021-02-25T08:28:41.117Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onclose>: Channel closed: 1006
JVB Side:
Several logs like,
[confId=9d71074c099283d0 epId=b9922c6b gid=413976 stats_id=Viola-0g8 conf_name=enginesin@conference.meet.com] VideoParser.transform#74: Unable to find encoding matching packet! packet=RtpPacket: PT=100, Ssrc=358628010, SeqNum=53464, M=true, X=true, Ts=1460079164, encodings=MediaSourceDesc 1604882424 has encodings:#012 primary_ssrc=358628010,secondary_ssrcs{404737831=RTX},layers=subjective_quality=0,temporal_id=-1,spatial_id=-1
At that stuation, if there was a screen sharing, resumed participant can see sharing at small thumbnail but not at main video section. did you faced with that problem before?
Client open this new websocket but also try to open old one also. Probably old one has invalid pwd at that moment. There is lots of failed colibri websocket exist…
Edit:
As i suspect:
jvb: WARNING: [767779] [confId=9d71074c099283d0 epId=0f42bd80 gid=413976 stats_id=Viola-0g8 conf_name=enginesin@conference.meet.bip.com] Endpoint.acceptWebSocket#969: Incoming web socket request with an invalid password. Expected: 276g0gb0loos3naa8viqshb165, received angft2hueg0537bhniv7564cm
When i update JVB to latest stable version 5390, that problem is also solved… With stable 5076, after user resumed, there is problem with jvb websocket which i mention about.
After setting up ejabberd, I can enroll users from multiple devices at the same time, and also log in multiple users, and users can communicate correctly, but the problem is when I quickly enroll multiple users from one mobile device.
Do i need to change anything at prosody side? for example if client goes to offline, we kick that client after a while. does this change effect prosody websocket timeout?
Are you using bosh or websocket for the signaling (mind that this is different than the websocket that is used for the jvb connection)?
In case of bosh you can control the timeout through property in prosody, but for it you need to use a custom lib-jitsi-meet with custom strophe.js build with a change for the timeout, cause per specs the timeout for bosh is 60 secs and that is hardcoded in the library.
For websockets there is no timeout as it is not a long poll as bosh, if the connection is dropped the session is destroyed.