`MessageEditData` is used to carry a new `MessageData` when an edition has happened, while
`MessageEdition` is used to send changes to do for a new edition.
"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.
This command has 2 subcommands: `make` and `receive` to make a new call or wait for one.
When call is in progress, a window will be created to show incoming stream and local
feedback, and a text UI is available to (un)mute audio or video, and hang up.
rel 426
it may be necessary to run some async cleaning method (e.g. if bridge is needed), this new
method handles async cleaning method, and will be called when `SystemExit` is used, or if
`a_quit` is called explicitely.
rel 426
this is a factored implementation usable by all non-web frontends. Sources and Sinks can
be configured easily to use tests source or local webcam/microphone, autosinks or a
`appsink` that the frontend will use.
rel 426
- `run_from_thread` can be used to run a method from a thread.
- `maybe_async` can be used to run a method if we are not sure if it's async or not.
- `install_glib_asyncio_iteration` run the GLib loop from asyncio one's.
rel 426
- 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
