Mercurial > libervia-backend
view doc/libervia-cli/info.rst @ 4231:e11b13418ba6
plugin XEP-0353, XEP-0234, jingle: WebRTC data channel signaling implementation:
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
| author | Goffi <goffi@goffi.org> |
|---|---|
| date | Sat, 06 Apr 2024 12:57:23 +0200 |
| parents | c4464d7ae97b |
| children |
line wrap: on
line source
================================== info: retrieve various information ================================== ``info`` groups subcommands used to retrieve read-only informations. disco ===== Display discovery information, including external discovery (see `XEP-0030`_ and `XEP-0215`_ for details). This can be used to check which features you server or a service is offering, which items are available (items can be services like chat room, gateways, etc), ans which external services (i.e. non-XMPP services) are proposed. You only have to specify the jid of the entity to check, and optionally a node. If a node is specified, external services won't be retrieved even if ``all`` is used (as external services don't have the notion of "node"). By default everything is requested (infos, items and external services), but you can restrict what to request by using ``-t {infos,items,both,external,all}, --type {infos,items,both,external,all}`` where ``both`` means infos and items, and ``all`` mean than + external services. .. _XEP-0030: https://xmpp.org/extensions/xep-0030.html .. _XEP-0215: https://xmpp.org/extensions/xep-0215.html example ------- Request infos, items and external services from a server:: $ li info disco example.org version ======= Request software version of an entity. You only need to specify the jid of the entity as positional argument. Depending of the software and its configuration, you have software version, software name, and the operating system on which the software is running. example ------- Check version of a server:: $ li info version example.org session ------- Give information about the session of the given profile. You'll get the full jid currently used on the server, and the time when the session was started (which may not be the same time as when the connection with the XMPP server was started). example ------- Get session informations:: $ li info session devices ------- List known devices for an entity. You'll get resource name, and data such as presence data, and identities (i.e. name and type of the client used). If entity's bare jid is not specified, a list of your own devices is returned. example ------- List known devices of Louise:: $ li info devices louise@example.org Check if we have other devices connected:: $ li info devices