After deploying on a remote server I noticed that messaged sent over sendEndpointMessage may arrive at a different order than they are sent. I saw that it’s in principal possible to disallow UDP for data transfer, but couldn’t find it in the jitsi client.
Is there a way to gurantee the order of messages sent?
I use it to send files with the size of multiple MBs. I have to split them up, otherwise my channel gets disconnected on big files.
Order should be guaranteed if you use the WebSocket transport.
That said, we never intended that channel be used for that purpose so might run into limits to prevent DoS kind os scenarios.
Where can I check if I enabled websocket transport / where can I configure that?
After this: RTCDataChannel.ordered - Web APIs | MDN
Ordering should be guranteed by default, but I couldn’t find the place in the code where a data channel is created.
I use conference.sendEndpointMessage("",{}) inside a for loop to send multiple pieces of a file.
On localhost I get the same order. But in a network scenario the order is not always the same.
Have you enabled SCTP in your JVB? If not you’ll be using WebSocket. You can also look at your JS console logs and search for “BridgeChannel”.
Seems like it uses websockets?
2022-06-14T15:32:37.916Z [modules/RTC/BridgeChannel.js] constructor() with wsUrl:"wss://192.168.178.80:8443/colibri-ws/172.22.0.5/3cd675cb973f3308/0a542873?pwd=7viveav6dahoub8h29fmajat2p" Logger.js:154:22
2022-06-14T15:32:38.214Z [modules/RTC/BridgeChannel.js] <_handleChannel/e.onopen>: websocket channel opened Logger.js:154:22
2022-06-14T15:32:38.221Z [modules/RTC/BridgeChannel.js] <sendReceiverVideoConstraintMessage>: Sending ReceiverVideoConstraint with maxFrameHeight=2160px Logger.js:154:22
2022-06-14T15:32:38.224Z [modules/RTC/BridgeChannel.js] <sendSelectedEndpointsMessage>: Sending selected endpoints: 9557ffdb. Logger.js:154:22
2022-06-14T15:32:38.225Z [modules/RTC/BridgeChannel.js] <sendReceiverVideoConstraintMessage>: Sending ReceiverVideoConstraint with maxFrameHeight=2160px Logger.js:154:22
2022-06-14T15:32:38.225Z [modules/RTC/BridgeChannel.js] <sendVideoTypeMessage>: Sending VideoTypeMessage with video type as camera Logger.js:154:22
2022-06-14T15:32:38.312Z [modules/RTC/BridgeChannel.js] <_handleChannel/e.onmessage>: Received ServerHello, version=undefined. Logger.js:154:22
2022-06-14T15:32:38.315Z [modules/RTC/BridgeChannel.js] <_handleChannel/e.onmessage>: Dominant speaker: 0a542873, previous speakers: 9557ffdb Logger.js:154:22
2022-06-14T15:32:38.767Z [modules/RTC/BridgeChannel.js] <sendReceiverVideoConstraintMessage>: Sending ReceiverVideoConstraint with maxFrameHeight=2160px Logger.js:154:22
2022-06-14T15:32:38.816Z [modules/RTC/BridgeChannel.js] <_handleChannel/e.onmessage>: SenderVideoConstraints: {"idealHeight":180} Logger.js:154:22
2022-06-14T15:32:49.039Z [modules/RTC/BridgeChannel.js] <_handleChannel/e.onmessage>: SenderVideoConstraints: {"idealHeight":0} Logger.js:154:22
2022-06-14T15:32:49.047Z [modules/RTC/BridgeChannel.js] <_handleChannel/e.onmessage>: SenderVideoConstraints: {"idealHeight":1080} Logger.js:154:22
2022-06-14T15:32:49.588Z [modules/RTC/BridgeChannel.js] <_handleChannel/e.onmessage>: New forwarded endpoints: 9557ffdb
Yes indeed, that’s the WS URL right there.