For a research project I want to modify jitsi and add some functionality.
My goal is to use the existing WebRTC Channel to send custom data between two people. But I struggle to find the Webbrowser implementation, I only find react native related code to webRTC or RTCPeerConnection.
I couldn’t find any documentation about it. Can someone point me to the right direction?
Best regards
Checck the sendEndpointMessage function in JitsiConference.
When using following code.
window.APP.conference.sendEndpointMessage("",{test:"hi"})
I get no error, but I struggle to find documentation for the other end, where I can register an listener or similar.
The only way I managed to get something to another participant was via:
import conference from '../../../../conference';
...
conference.commands.addCommandListener("sendCommand",function(){console.log("command received")});
window.CONF = conference;
Executing in devtools console:
window.CONF.commands.sendCommand("sendCommand",{tagename:"jo"},"h2i")
but when I execute the same command/tagname, I get no “command received” on the second request, only if I alternate between 2 tags, I get everytime a “command received”.
I guess commands are batched so a command doesn’t get executed twice?
I know that sendEndpointMessage was suggestes, but as stated above I was not able to receive a message (perhaps because I couldn’t find the right way to do it)
Best regards
Edit: I also just noticed, that commands seem not to carry any payload information
conference.commands.addCommandListener("sendCommand",(data)=>{
console.log(data,"send command listener")
});
After I gained some experience with redux in jitsi I’m able now to receive messages.
I’m able to send data with custom payload and receive it.
In case anyone faces the same problems:
in your reducer.js file inside react/your-component-folder
ReducerRegistry.register(STORE_NAME, (state = DEFAULT_STATE, action) => {
switch (action.type) {
case "ENDPOINT_MESSAGE_RECEIVED":
console.log(action)
break;
}
});
In devconsole:
window.APP.conference.sendEndpointMessage("","hello")
window.APP.conference.sendEndpointMessage("",{json:"also possible"})
You have to watch for the action.type “ENDPOINT_MESSAGE_RECEIVED” which is dispatched when calling sendEndpointMessage.
Questions I still have:
1. I’m not 100% sure if I have to create a middleware for it, when my reducer is registered last? I saw that multiple reducers deal with ENDPOINT_MESSAGE_RECEIVED actions, but my is the only which should handle the sent files.
2. The last problem I have is, that I can’t send binary data like a file that was uploaded via a input tag. WebRTC is capable to send binary data directly without converting it to base64. Is this also possible in jitsi?
in devconsole
window.APP.conference.sendEndpointMessage("",$0.files[0])
results in an empty json object
Object { type: "ENDPOINT_MESSAGE_RECEIVED", participant: {…}, json: {} }
3. . I was wondering how to check if messages actually went thorugh the (p2p) WebRTC channel?
Thank you for your time
You don’t always need a middleware.
All of them likely check for the message type. Make sure your messages have a unique one.
No, our bridge channel uses a websocket connection and it serializes the content to JSON.
There is no p2p channel per se, it always goes through the JVB.
Is this possible to access the RTCConnection which is created by jitsi and used for video/audio in a p2p connection?
I guess the same goes for chat messages, that they are sent over the JVB?
Not at the moment.
They are sent through Prosody.
Is it the same for video and audio that they always go thorugh the JVB, even in a 2 person meeting?
No, in a 2 person meeting audio and video may go directly, if a direct path is found.
Is there also a way to send custom data directly in a p2p conference?
My usecase is to send files (each up to 20 MB) from one participant to another participant preferably in a p2p connection. I know that for big files I have to send the files in many slices.
On this pages it states, that the bridge supports both (webrtc and websocket)?
To summarize:
video/audio: goes through the videobridge or directly in a p2p conference
Chat messages: are sent through prosody (xmpp-websocket) no matter if its a p2p conference or not
commands : same as chat messages?
sendEndpointMessage: same as chat messages?
Thank you for your time 
Not with the tools we provide.
Yes, but that’s between each peer and the JVB.
Almost
commands are XMPP presence
sendEndpointMessage is the bridge channel: WS or datachannel, but through the bridge.
Sorry that I have to ask again.
I couldn’t find what a XMPP “presence” is.
This is the JVB? So sendEndpointMessage uses either WebRTC or Websocket?
If so what is the difference to audio/video transfer? I’ve read that even in a p2p conference the traffic is routed through the JVB?
Endpoint messages are over websocket and are transported as json messages, they are not designed for data. Audio and video go over UDP.
So it’s not recommended to use the current API, since they are not made for data transfer? After my testing with the command and sendEndpointMessage API I can say, that sendEndpointMessage seems to be more performant for data sending.
If you want a true P2P datachannel, you could use either chat or endpoint messages to negotiate another WebRTC connection, where you only use the datachannel. This would be all in your app code, you’d just use our messaging mechanisms to establish this extra connection.
in XMPP entities are meeting in rooms. They are announcing their presence in the room by sending messages saying ‘I’m here, this is what I am and what I can do’. These messages are called ‘presences’. You can read about XMPP here.
Jitsi-meet is built around Prosody, a Xmpp server, that is, something that is built to exchange messages (and can exchange data too) between users. Everything is here and well documented.
Can you show me how I etablish a extra connection / where the connection is created in jitsi meet, so I can create one myself?
Find any webrtc demo how to create a P2P connection so you can have the signaling part tested outside jitsi-meet and then the jitsi meet part is as easy as sending a message and listening for it on the other end.