view doc/libervia-cli/debug.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 524856bd7b19
children
line wrap: on
line source

=====================================================
debug: tools to help debugging/monitoring Libervia
=====================================================

``debug`` groups commands to monitor or manipulate Libervia and XMPP stream.

.. _li_debug_bridge_method:

bridge method
=============

Call a method of the bridge. You have to provide the name of the method and the arguments
as positional arguments. Arguments are evaluated as Python code (using ``eval``), so you
need to properly escape them (for your shell **and** Python). You can either split your
Python arguments as many shell arguments, or put them in a single shell argument.

You profile is automatically set if the method requires it (using the value of ``-p
PROFILE, --profile PROFILE``), so you must not specify it as an extra argument.

You can refer to `bridge API documentation`_ to get core methods signatures

.. _Bridge API documentation: https://wiki.goffi.org/wiki/Bridge_API


examples
--------

Send a message using a single shell arguments for all Python arguments. We
use first the method name (``message_send``), then the required arguments (see `bridge
API documentation`_ for details), without the profile as it is automatically set. We
specify them as Python in one shell argument, so we use single quote (``\```)first for
s hell string, and inside it we use double quote (``"``) for Python strings::

  $ li debug bridge method message_send '"louise@example.org", {"": "test message"}, {}, "auto", {}'

.. note::

  This is for debugging only, if you want to send message with li, use :ref:`libervia-cli_message_send`.

Get version string of Libervia::

  $ li debug bridge method version_get


bridge signal
=============

Send a fake signal. This is specially useful to test behaviour of a frontend when a
specific event happens. To use is you just need to specify the name of the signal and the
arguments to use (using Python eval in the same way as for libervia-cli_debug_bridge_method_).

example
-------

Send a note with ``info`` level and hand written XMLUI. Here me use a shell variable to
store the level, so we can easily change it if we want to use an other level for tests.
Note the use of quotes (to escape both for shell and Python)::

  $ LEVEL='info'; li debug bridge signal -c action_new '{"xmlui": '"'"'<?xml version="1.0" ?><sat_xmlui title="test title" type="dialog"><dialog level="'$LEVEL'" type="note"><message>test message\non\nseveral\nlines</message></dialog></sat_xmlui>'"'"'}' '""' -1


monitor
=======

Show raw XML stream. By default, output is pretty formatted/highlighted and you get all
streams in both direction. You can filter the direction using ``-d {in,out,both},
--direction {in,out,both}``.

For this to work, you need to set the option ``Activate XML log`` in the ``Debug`` section
of your parameters.

Verbosity is used, to print details on the direction of a stanza, use ``--verbose, -v``

example
-------

Monitor raw XML stream::

  $ li debug monitor -v

theme
=====

Show the colour constants in their respective colour, according to background (``light``
or ``dark``). If backround option is not set in ``libervia.conf``, it will be autodetected, and
colour theme will be modified accordingly.

example
-------

Show colours with the set background::

  $ li debug theme