Implement XEP-0343: Signaling WebRTC Data Channels in Jingle. The current version of the
XEP (0.3.1) has no implementation and contains some flaws. After discussing this on xsf@,
Daniel (from Conversations) mentioned that they had a sprint with Larma (from Dino) to
work on another version and provided me with this link:
https://gist.github.com/iNPUTmice/6c56f3e948cca517c5fb129016d99e74 . I have used it for my
implementation.
This implementation reuses work done on Jingle A/V call (notably XEP-0176 and XEP-0167
plugins), with adaptations. When used, XEP-0234 will not handle the file itself as it
normally does. This is because WebRTC has several implementations (browser for web
interface, GStreamer for others), and file/data must be handled directly by the frontend.
This is particularly important for web frontends, as the file is not sent from the backend
but from the end-user's browser device.
Among the changes, there are:
- XEP-0343 implementation.
- `file_send` bridge method now use serialised dict as output.
- New `BaseTransportHandler.is_usable` method which get content data and returns a boolean
(default to `True`) to tell if this transport can actually be used in this context (when
we are initiator). Used in webRTC case to see if call data are available.
- Support of `application` media type, and everything necessary to handle data channels.
- Better confirmation message, with file name, size and description when available.
- When file is accepted in preflight, it is specified in following `action_new` signal for
actual file transfer. This way, frontend can avoid the display or 2 confirmation
messages.
- XEP-0166: when not specified, default `content` name is now its index number instead of
a UUID. This follows the behaviour of browsers.
- XEP-0353: better handling of events such as call taken by another device.
- various other updates.
rel 441
the `C.META_TYPE_FILE` can't be used in this case as it is a preflight and we don't have
yet data such as progress ID. `C.META_TYPE_FILE` is used as a sub-type to help with dialog
management in frontend.
when a peer jid was not in our roster, devices list was not retrieved, resulting in failed
en/decryption. This patch does check it and download missing devices list in necessary.
There is no subscription managed yet, so the list won't be updated in case of new devices,
this should be addressed at some point.
Use of `pickle` to serialise data was a technical legacy that was causing trouble to store
in database, to update (if a class was serialised, a change could break update), and to
security (pickle can lead to code execution).
This patch remove all use of Pickle in favour in JSON, notably:
- for caching data, a Pydantic model is now used instead
- for SQLAlchemy model, the LegacyPickle is replaced by JSON serialisation
- in XEP-0373 a class `PublicKeyMetadata` was serialised. New method `from_dict` and
`to_dict` method have been implemented to do serialisation.
- new methods to (de)serialise data can now be specified with Identity data types. It is
notably used to (de)serialise `path` of avatars.
A migration script has been created to convert data (for upgrade or downgrade), with
special care for XEP-0373 case. Depending of size of database, this migration script can
be long to run.
rel 443
An https:/salut-a-toi.org URL was used to retrieve external IP, but it's not valid
anymore, resulting in an exception. This feature is currently disabled.
Also moved several methods from legacy inline callbacks to coroutines.
the plugin was using python-dbus which is deprecated in the backend in the favor of
TxDBus. Methods calls have been updated, and the plugin works again, but there seems to be
still some issues (warnings in the logs). Those will be fixed later.
OLDMEMO was applied at the `send_message_data` trigger level, however this was missing
stanza constructed without message data (which is notably the case for XEP-0308). This has
been fixed by using the `send` trigger instead. As a side effect, the same code is now
used for TWOMEMO and OLDMEMO, making it simpler.
"Message Reactions" implementation is now working and updating history. The
`message_reactions_set` bridge method can be used by frontend to `replace`, `add`,
`remove` or `toggle` reactions. History is properly updated, and signal are sent when
necessary.
even if the XEP doesn't specify if Message ID must be the same as `origin_id`, using a
different one makes little sense, and is leading to bugs in other implementation (e.g.
Movim using the wrong ID for reactions).
- workflow is now using the normal messages workflow even for history message: previous
workflow was dedicated to MUC and only adding message to history, resulting in other
plugins being skipped.
- new `get_room_user_jid` helps to retrieve easily the JID currently used in a joined
room.
- use `9` as port placeholder
- add `a=ice-options:trickle` to indicate that ICE candidates may be sent after SDP
- moved senders mapping at media level
- fix `rtpmap` channel setting
- don't overwrite existing `fingerprint` data
rel 424
media content order is relevant when building Jingle contents/SDP notably for bundling.
This patch fixes the previous behaviour of always using the same order by keeping the
order of the data (i.e. order of original SDP offer). Previous behaviour could lead to
call failure.
rel 424
- add a `jingle_preflight_info` method in the Jingle Application model to handle this kind
of information
- XEP-0353 is calling `jingle_preflight_info` when a `ringing` message is received
- XEP-0167 use this information to send a `ringing` info to frontends
- XEP-0166: add `jingle_preflight` and `jingle_preflight_cancel` methods to prepare a
jingle session, principally used by XEP-0353 to create and cancel a session
- XEP-0167: preflight methods implementation, workflow split in more methods/signals to
handle UI and call events (e.g.: retract or reject a call)
- XEP-0234: implementation of preflight methods as they are now mandatory
- XEP-0353: handle various events using the new preflight methods
rel 423
