-
Notifications
You must be signed in to change notification settings - Fork 15
Support XEP-0167 (voice calls) #135
Comments
Agree. I also want to have that :-)! But this is more difficult then it seems to be. And given the current man-power, it does not look like this feature will be implemented in the near future... |
Can you outline, what needs to be done? |
I have not looked into the details yet. But this is a starting point: |
Thanks! I have read through the things a little bit. I understood, that a minimal implementation needs
In swiften there seems to be no support for this extensions. Since swiften seems to be quite unmaintained, may be a switch over to qxmpp library would be worth thinking about. Following https://doc.qxmpp.org/qxmpp-dev/xep.html Qxmpp supports the XEP feature list of shmoose like this:
and it also supports
Of course this is no shortterm solution, but neverthless: What is your opinion about it? |
Agree. There is not much action on Swiften. But to switch to qxmpp is a major rewrite of a lot of the code base. Maybe this step is necessary for new features. Currently, I don't have the resources to do that. If you want to help, maybe there is a dual approach. |
I have tried to build it. v1.1.0 works with Qt5.6. v1.2.0 already requires Qt5.7. I have built it with:
v1.1.0 not supports the following XEPs. But shmoose is only affected by XEP-0359.
|
I did not expect to get a newer Qt version soon at SFOS. And with Qt 6, they changed their licensing model. And Jolla probably has to pay license fees, if they want to switch to that v6 version. This having said, going with qxmpp seems a dead-end on SFOS. Maybe we should switch to nemo-mobile as a target OS ;-). Even if we go with v1.1.0, if there is a security risk, we can't just update to a newer version. From a technical point of view... |
This problem with the license / Qt was new for me. So I read only a little bit about it. From my point of view, Qt could be also in the future an alternative. Because either Sailfish OS will solve the licensing issues and update to a newer version or it will switch to another library, but than it would be no problem to ship Qt as an additional rpm. I personally would put my coins on the first one. Assuming, either way will be the future, the problem is, getting security fixes and enhancements for qxmpp meanwhile. |
Hi, I've been able to get a start of an implementation supporting XEP-0166/XEP-0167/XEP-0176 with Swiften. Swiften already supports Jingle. I added classes to get RTP transport description and ICE-UDP. This is at an embryonic stage. Therefore to make it work I had to make a small patch to Swiften. I'm able to get debug traces when a call is received. |
Sounds good. It's a first step. Please get us updated :-). |
Work is in progress. It takes time to write all the classes in the same manner as Swiften, and then a Stun client, and then to connect to speaker and to microphone. I'd like to get it work with Conversations: SRTP - DTLS (XEP-0320) has to be supported. So it adds some complexity. |
Just a thought. But maybe it could also be an option to have a look, what is needed to get qxmpp to build also with the Qt version Sailfish supports. Maybe there are only a few places in the qxmpp code where a decision needs to be placed about the target Qt version and add some code for that version. The guys from qxmpp had to agree to accept those changes as a merge request. Someone could ask them ;-). But with this, in my opinion, it would make sense to start a new SFOS xmpp client from scratch. To refactor shmoose away from swiften to only use qxmpp is a major task. I can't handle this with the amount of available time. And it would bring the possibility to have a test-driven development from the very beginning. Shmoose is now at a point, where every change in the code could break something. And the (integration) test coverage of about 60% is not enough. It needs a test for every class, which is not there at the moment. |
For those of you (@jlaba ?) who want to play around with qxmpp, if have cloned the repo into qxmpp-sfos and inserted a little patch file to make it build on sfos. Use it with: patch -p1 <sfos.patch |
You mean patch -p1 <sfos.diff :) |
I compiled easily the QXMPP library and I ran a couple of examples successfully.
But I'm blocked when I need to use the libomemo-c library in Qxmpp. I never know how to proceed to make the library accessible to Qxmpp for compiling... |
That was also my next step on my todo list, to test the omemo build ;-). Do you have a patch with your changes? |
Ok, I built libomemo-c for sfos and patched the qxmpp cmake files to use this library. |
Maybe it make sense to just build it [1] by our own. I will try it... |
I build qca 2.2.1 and libomemo-c from master. Now, I also get a number of error messages in qxmpp with omemo enabled. The omemo stuff is implemented by using even more modern c++ then SFOS can handle. Let me think about if it is worth to follow this path and patch away the modern constructs by old workarounds... |
If you want to give it a try, I have updated the diff file. CMakeLists of qxmpp is updated to build against the local builds. Use this steps (out of my head, adjust as needed ;-)) mkdir xmpp && cd xmpp wget https://github.com/KDE/qca/archive/refs/tags/v2.2.1.tar.gz https://github.com/dino/libomemo-c git clone https://github.com/geobra/qxmpp-sfos |
Done. With the latest commit of the sfos.diff, qxmpp with enabled omemo builds for sfos. Where to go from here with Shmoose, @ron282 ? As @jlaba correct pointed out, Swiften did not get new features or bug fixes for quite a while now. The patches to qxmpp are small and clear. But can become bigger and more complex in the future. From my point of view, there are some options:
And if we want to switch to qxmpp
Lots of stuff to decide... |
That's a great news. I look at the qxmmp api and it looks clean and much more easier to integrate with Shmoose. I looked also at Swiften for audio calls and I spent some time trying to figure out what needs to be done. This is quite complex. I'd rather go with adapting Shmoose for qxmpp but I let you decide! If I can help i would be happy to help for that. |
I did a Shmoose version (qxmpp branch) which is using qxmpp for roster. It works. |
Okay, lets try it with a simple prove of concept first. With a goal to have the roster and be able to send simple 1to1 messages. Thats it, no other stuff or XEPs. With this, we will get a feeling about the effort. I will create a new project, based on the Shmoose Master. And exclude most of the classes from the build. Based on that, try to exchange swiften with qxmpp. Then we can start by exchanging the API calls and get back the actual functionality. Give me some days to prepare this. |
Just a quick feedback. Excluding stuff and getting the MVP compiling is ongoing. Had to think about how to structure it best. But in the end, the architecture will not change much and qxmpp will be included in a similar way as swiften was... |
Here is a cloned repo from Shmoose. It assumes to have the build qxmpp lib ready, parallel to the shmong directory. But @ron282 ... During the work of refactoring the last days, I noticed that I did not have the time to really actively work on this. In the old times I started shmoose, about 6 years ago, I was more in programming then today. So, if we want to go to try this change with qxmpp, I can assist you with hints on how things work. The main coding stuff would be on you. Saying that, think about if you want to 'own' the new xmpp client as a project, hosted on your github account. Or if I should add you as a main developer to the Shmong repo. What is your opinion about that all? |
Hi @ron282 I manually merged a lot of your code from your harbour-shmoose -> qxmpp branch into shmong. The Desktop client is now working with this. The roster is processed and displayed. And it is possible to send and receive 1to1 messages. Maybe we should stop now discussing here and open a new thread in an appropriate repository ;-). |
Hi @geobra , that's very good news! On my side i'm trying now since 3 weeks to create .spec files to compile libomemo, qca and qxmpp. I'm using sfdk to compile. I'm not a cmake expert so it's a slopy learning curve. I'm sucessfull with libomemo but i'm blocked with qca. Now you have something running i will have a look. This is more intrresting! Ok to.continue silewhere the discussion but we will have to come back later. Everything started because of calls! |
Support at least for audio calls via XEP-0167 would be nice. Is it already on the roadmap?
The text was updated successfully, but these errors were encountered: