How to join a meet from the backend?

Developers
1

Hi there!

First, thanks for this amazing open-source project. For the most part I was able to extend it without any help, and with great results. Which means the code-base is really good, so yeah, thanks for that.

I’m trying to join a meet from the backend and get a hold of the Audio and Media Streams. The end goal is to join as another participant and reproduce sounds and video. The “join meet” stimulus is received through a REST endpoint that receives “the room name/url/whatever and the username”.

I’ve based my implementation on Jigasi (was about to use jibri but under the hood it leverages the webrtc api from the browser, and i’d like to avoid a headless chrome, and use only java/kotlin). So far I created a Gateway and a GatewaySession based on the existing Sip and Jvb implementations but i’ve reached a dead end when processing an incoming call.

JvbConference.java @ jigasi, expects a CallContext in the constructor, which is built from a CallEvent object. I’m a bit lost on how to build a CallEvent, since my stimulus comes from a REST endpoint and not within wherever comes from Jigasi.

I imagine that instead I should query somehow the videobridge or jicofo using the roomname, and then somehow create a Call object and somehow Join (too many somehows ha!)… But im really lost. Tried to decompile the code and search on Github but when i get to jitsi-protocol it gets really confusing.

So yeah, any tip/hint would be greatly appreciated. I’m more than willing to do some research on my own, but I really need a hint :confused:

Thanks again!

2

Jigasi is audio only. If you want to use java only for the video you will need to implement many of the protocols and codec-related stuff that are already available in webrtc which are missing in jigasi. So I would say this is an enormous project …

Jigasi joins the muc as the rest of the clients and it is jicofo sending the jingle session-initiate for establishing the media path to jvb. The CallEvent is the incoming call invite.

3

Did you check gst-meet?

1 Like
4

Hey guys, how are you doing?
I’m working on the gst-meet integration (with Diego Moreira). It seems all is well configured since we don’t see any errors. But we are not able to send any sound file to the conference or save any webm file with the call conversation. I mean, we are able to execute the gst-meet commands without errors, but nothing happen. Do you know if we need a specific Prosody/Jitsi version? Thanks in advance guys :slight_smile:

Just one more clarification: we are testing with a video-call with the Jitsi domain directly (meet.jit.si), there is nothing with our configuration in the middle.

Thanks again!

5

@jbg

1 Like
6

Hey guys, it’s me again :slight_smile:

I was able to advance a little more with the gst-meet integration. Now gst-meet appears as a meeting participant, but I am not able to hear the sound that I sent from the terminal yet.

I have this new log:
DEBUG IQ did not successfully parse as Jingle: ParseError(“Element transport must not have more than one web-socket child.”)

Is there any recent modification in jitsi jingle messages? Could you please take a look? Thank you very much!

reference:

7

Hey @emrah :wave: , just in case you could take a look :pray: I can't send audio files or save the resultant conversation file. · Issue #69 · avstack/gst-meet · GitHub

Thanks a lot.

8

Hi @Lorena_Pressiani,

I’m not familiar with gst-meet. Its developer is @jbg. I think he will check your post when he is available.

9

yes, thanks, it is just I put a comment about the messages received from Jitsi :slight_smile:

10

Hi @Lorena_Pressiani I have replied to the GitHub issue you filed; the issue is caused by a change in Jitsi Meet signalling protocol which is not yet supported in gst-meet. You can either wait for a new gst-meet release which supports the new signalling protocol, or use a backend (your own or some other) running an older version.

11

ok @jbg thank you very much. I replied to the github thread before seeing this, sorry.
I thought there would be a workaround in the meantime.

12

@jbg could you please let me know what is the Jitsi compatible version? Thankss

13

Hey @emrah! I am testing against your domain, and I could obtain the expected result. But this happens only when I am connected to this shard:

Could you please let me know what is the feature you have in that shard? Is the version 3878? Is that version in any published docker image here: Releases · jitsi/docker-jitsi-meet · GitHub?
Because I can’t find it.

The behaviour that I am experiencing is that I am able to receive the stun server data and then I can join to the meeting.

<iq xmlns='jabber:client' to='f4a6359a-e3e3-47a6-8f51-63623349af24@meet.jit.si/t13oHO2XVQb9' from='meet.jit.si' id='d59648fe-e53e-4234-93a9-6c282d11a3e8' type='result'>
<services xmlns='urn:xmpp:extdisco:2'>
<service host='meet-jit-si-turnrelay.jitsi.net' transport='udp' type='stun' port='443'/>
<service host='meet-jit-si-turnrelay.jitsi.net' expires='2023-03-08T21:42:55Z' transport='udp' port='443' restricted='1' username='1678311775' password='egCLjACeu51YepIYo9FkcA0tqD4=' type='turn'/><service host='meet-jit-si-turnrelay.jitsi.net' expires='2023-03-08T21:42:55Z' transport='tcp' port='443' restricted='1' username='1678311775' password='egCLjACeu51YepIYo9FkcA0tqD4=' type='turns'/>
</services>
</iq>

Thanksss.

14

Hi @Lorena_Pressiani,

I’m not a member of Jitsi Team, maybe @damencho helps you to find this info.

15

Thanks @emrah

@damencho do you have that information please? We invested a lot of time in this analysis and it would be great to finish it asap :slight_smile: Or, at least, define if our integration is not possible and close the topic.

Thanks a lot.

16

What is the question?

meet.jit.si has only one release and the release number has nothing to do with jitsi-meet version. So any shard from that release will have the same version. To check the version the easiest way is to open the index.html.

<base href="https://web-cdn.jitsi.net/meetjitsi_7016.3792/" />

So this is jitsi-meet-web 7016. This is https://download.jitsi.org/unstable/jitsi-meet-web_1.0.7016-1_all.deb
Or if you want to know the jitsi-meet version the correct matching needs to be done either from the debian packages or from the repo Updates jitsi-meet-web: 7016 · jitsi/jitsi-meet-debian-meta@963bdd9 · GitHub check the tag this commit belongs to.
This is jitsi-meet 2.0.8346.

17

Hey @damencho, thanks for your answer.

Someone told us that “meet.jit.si may not always run the same version in all shards, they might use some shards to test new versions, or do upgrades shard-by-shard.” Then, given I was experiencing different behaviours in my tests without changing anything on my side, I thought that it could be a specific feature deployed in the sao paulo shard (which is the one that always is working as I expect, I don’t know why). When the shard is, for example, the london one, I can’t connect my application because I don’t have the message I attached before with the stun data. As context: the product we are trying to integrate parse that message (with the stun configuration); when that info is not present… the flow can’t continue the execution.

On the other hand, as jbg mentioned in a previous comment, there was a change in Jitsi Meet signalling protocol which is not yet supported in gst-meet, and we need a version without those changes.

Maybe in my previous message I mess up the information, sorry.

18

Oh, I didn’t have this context before. Jitsi Meet has a prosody plugin called mod_jiconop, and one of the things it does is send the “external services” (STUN/TURN servers) immediately after bind, to speed up the connection process (since otherwise the client has to request them). But there is no guarantee that you will receive that stanza in any particular order relative to the other stanzas being sent around the same time, and in fact you should not even rely on it being sent, because some servers may not run this module (I have no idea if meet.jit.si does or not), so you should be prepared to request the external services if you need them.

19

@jbg Hey, thans for the response. We’ve been trying different approaches and none of them worked so far.

Can you confirm if TURN is mandatory for gst-meet to work?

Our current stack uses google’s STUNs and we dont have a TURN and STUN stack running (we dont need them for our use-case).

Looking at the RUST code and adding logs to gst-meet we believe this may be the issue.

And also the only difference with meet.jit.si we believe is the lack of STUN/TURN.

Can you help us confirming if that is the case?

Thanks and thanks for the patience too!!!

20

Only if the network conditions between gst-meet and JVB mean that TURN is needed. In other words, it should be the same as a browser running on the same machine. That said, we have not tested it in an environment where the server does not offer a TURN external service. There may be some assumption in the code that a TURN external service is provided.

1 Like