XSF Discussion - 2020-10-26

I'm slightly stuck with XEP-0338 (jingle grouping). For example I want to open a session for voice, video and file transfer bundled in one p2p connection. But at the moment of opening there were no files to transfer, the files are expected to appear later. So basically I want to put into BUNDLE grouping something that doesn't exist yet. The XEP says nothing about group updates. So how to handle this?

https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-54#section-7.5.1 describes updated for SDP. I believe same technique is applicable to XMPP too. I'd prefer to explicitly mention this in the XEP.

For which Server do you want to use this?

Oh he's gone already...

But I have a problem too. My users and I can send TXT or VCF files but can't download them in the Clients. I think it is a problem of prosodys internal http upload. But everything else just works fine. Only txt and vcf files didn't work. Did I misconfigured something with http upload? Http upload external works and shouldn't be the problem because the txt and vcf are small enough to go through the internal upload... ✏

Arne, check which mime types your server’s

... your server is serving

Arne, this seems more like a question for xmpp:operators@muc.xmpp.org?join

or maybe for the support room of your server

Ah sorry, just seeing.. Wrong room. Thanks jonas’ wurstsalat

:)

Arne: no server for now. just p2p.

I see and which clients?

Arne: Psi

I really want to have QUIC there but it's not yet ready for prod (libs are missing and conflicting with others. We need OpenSSL 3.0 for QUIC). But with QUIC there is no BUNDLE problem basically just because its XEP is not yet designed :)

Yes it's to early to use it

So I integrated usrsctp and took parts for MediaSoup to wrap it for Psi. For now I'm trying to design something in advance to have less refactoring later.

would it be possible to have something like Chat Markers but for Pubsub Items ?

basically to know if someone accessed and read the content of a Pubsub item

Arne: wrt design. I think ICE connections per contact/mediaserver have to be maintained by a dedicated controller. So when for example we want to share a file withing existing RTP session, it will try to find a suitable already opened ICE connection to the contact and BUNDLE its data (sctp) stream there. In this case jingle-ice application is just a user of such controller may serve as a kind of master application to negotiate ICE candidates. Unfortunately XEPs aren't explicit about such a use case too.

btw, just if anyone wants to implement its own sctp+datachannel lib. It's a terrible idea. There is way more work than it looks from the first glance. usrsctp is not ideal too (multithreading problems. lacks support for some cool sctp extensions) but it's well maintained and used everywhere.

If only we could have had actual SCTP :(

Or MPTCP

Sorry rion I think I can'z help with this..

Zash: time to design xmpp over QUIC. Same lib to open both xmpp and p2p connections. And all the encryption inside. Should be really cool. :)

like connect()?

:-X

is quic suitable for realtime data? can you tell it to ignore dropped stuff?

it is as far as I know. It supports unreleable streams.

Also I read some comparison doc sctp vs quic. And it seems quic is better by many aspects. But sctp gets new extensions regularly, so maybe the doc is already outdated (https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00).

A comparision between SCTP and QUIC by the QUIC working group? probably not biased.

=)