Support XEP-0167 (voice calls)

[jlaba]

Support at least for audio calls via XEP-0167 would be nice. Is it already on the roadmap?

[geobra]

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...

[jlaba]

Can you outline, what needs to be done?
May be I find some time to start the implementation.

[geobra]

I have not looked into the details yet. But this is a starting point:
https://xmpp.org/extensions/xep-0166.html

[jlaba]

Thanks! I have read through the things a little bit. I understood, that a minimal implementation needs

• XEP-0166 - Jingle Basics
• XEP-0167 - Jingle RTP Sessions (Voice or Video Calls)
• XEP-0176 or XPE-0177 - (both solutions to handle the data session)

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:

• XEP-0184: Message Delivery Receipts - ok
• XEP-0199: XMPP Ping - ok
• XEP-0363: HTTP File Upload - ok
• XEP-0333: Chat Markers - ok
• XEP-0313: Message Archive Management - ok
• XEP-0359: Unique and Stable Stanza IDs - ok
• XEP-0045: Multi-User Chat - ok
• XEP-0280: Message Carbons - ok
• XEP-0198: Stream Management - ok
• XEP-0384: OMEMO Encryption - only partially yet

and it also supports

• XEP-0166: Jingle
• XEP-0167: Jingle RTP Sessions
• XEP-0176: Jingle ICE-UDP Transport Method

Of course this is no shortterm solution, but neverthless: What is your opinion about it?

[geobra]

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.
First, test if qxmpp is build- and runable on SFOS. Then, try to use qxmpp side by side with the swiften framework in shmoose. By this, shmoose could use qxmpp for new features and step by step rewrite the 'old' code to also use qxmpp.

[jlaba]

I have tried to build it. v1.1.0 works with Qt5.6. v1.2.0 already requires Qt5.7.
Since v1.1.0 contains already the class QXmppCallManager it should work with this verison.

I have built it with:

../sailfishOS/bin/sfdk cmake . -- -DBUILD_TESTS=OFF -DBUILD_DOCUMENTATION=OFF -DBUILD_EXAMPLES=OFF
../sailfishOS/bin/sfdk make

v1.1.0 not supports the following XEPs. But shmoose is only affected by XEP-0359.

• Starting with v1.2.0 (requires >Qt5.7.0; ABI Change)
  • XEP-0077: In-band registration
  • XEP-0231: Bits of Binary
• Starting with v1.3.0 (requires >Qt5.7.0; complys with the XMPP Compliance Suites 2020)
  • XEP-0245: The /me Command
  • XEP-0357: Push Notifications: Enable/disable IQ
  • XEP-0359: Unique and Stable Stanza IDs
  • XEP-0428: Fallback Indication
• Starting with v.1.4.0 (requires >Qt5.7.0; requires C++17; compliance suites for 2021 - reached without changes)
  • XEP-0224: Attention manager
  • MIX-MISC XEP-0407: Invitation message extension

[geobra]

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...
With something like "swiften::client->onDataRead" you can get all the received xml as a string stream. Is it possible to forward that to qxmpp?

[jlaba]

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.

[ron282]

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.

[geobra]

Sounds good. It's a first step. Please get us updated :-).

[ron282]

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.

[geobra]

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.

[geobra]

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

[ron282]

You mean patch -p1 <sfos.diff :)

[ron282]

I compiled easily the QXMPP library and I ran a couple of examples successfully.
I tried to compile the OMEMO extension but I had few issues that may need additional lines in the sfos.diff because of differences in feature sets between Qt 5.6 and Qt 5.14:

• fromSecsSinceEpoch(a) has to be replaced by fromMSecsSinceEpoch(a*1000ul)
• toSecsSinceEpoch() has to be replaced by toMSecsSinceEpoch()/1000
• Qt::SkipEmptyParts replaced by QString::SkipEmptyParts
• Qt::KeepEmptyParts replaced by QString::KeepEmptyParts
• QOverload by static_cast...
• qAsConst by Q_FOREACH

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...