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

version: "3.6"
services:

  prosody:
    image: libervia/prosody:e2e
    build: prosody-e2e
    depends_on:
      # we need to depend on backend to get IP address of the container for conf
      - backend
    tmpfs: /var/log/prosody
    networks:
      default:
        aliases:
          - server1.test
          - server2.test
          - server3.test

  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: test_e2e
      POSTGRES_DB: pubsub
    tmpfs: /var/lib/postgresql/data

  pubsub:
    build: pubsub
    image: libervia/pubsub
    depends_on:
      - db
      - prosody
    environment:
      PGHOST: db
      PGUSER: postgres
      PGPASSWORD: test_e2e
      LIBERVIA_PUBSUB_RHOST: server1.test
      LIBERVIA_PUBSUB_JID: pubsub.server1.test
      LIBERVIA_PUBSUB_XMPP_PWD: test_e2e

  backend:
    image: libervia/backend:${DOCKER_LIBERVIA_REV:-dev}-e2e
    build:
      context: backend-dev-e2e
      args:
        REVISION: ${DOCKER_LIBERVIA_REV:-}
    environment:
      LIBERVIA_TEST_ENV_E2E: "1"
      LIBERVIA_TEST_ENV_E2E_WEB: "1"
    volumes:
      - libervia_data:/home/libervia/.local/share/libervia
    ports:
      # VNC server for Libervia e2e tests visual mode
      - 5900
    networks:
      default:
        aliases:
          - libervia-backend.test

  web:
    image: libervia/web:${DOCKER_LIBERVIA_REV:-dev}-e2e
    build:
      context: libervia-web-dev-e2e
      args:
        REVISION: ${DOCKER_LIBERVIA_REV:-}
    depends_on:
      - backend
    environment:
      LIBERVIA_PASSPHRASE: test_e2e
    volumes:
      - libervia_data:/home/libervia/.local/share/libervia
    ports:
        - "8080"
        - "8443"
    networks:
      default:
        aliases:
          - libervia-web.test

volumes:
  libervia_data: