[jitsi-users] Jitsi always using IBB for file transfer?


#1

Hi,

I am observing that file transfers through Jitsi are very slow. I
wondered why, and finding that out, I discovered that the file is
transferred as in-band bytestream through the XMPP connection.

While this obviously works, it makes for a lot of overhead.

Why doesn't file transfer use the same methods as audio/video?

On a side note: Why doesn't audio/video fall back to IBB if ICE fails,
now that IBB is obviously implemented ;)?

Cheers,
Nik

···

--
Wer den Grünkohl nicht ehrt, ist der Mettwurst nicht wert!

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296


#2

Hey Dominik,

Hi,

I am observing that file transfers through Jitsi are very slow. I
wondered why, and finding that out, I discovered that the file is
transferred as in-band bytestream through the XMPP connection.

While this obviously works, it makes for a lot of overhead.

Why doesn't file transfer use the same methods as audio/video?

Because this hasn't been implemented yet. We did implement pseudo TCP
(Pawel did that in 2012) but we haven't yet got around to integrating
jingle file transfer.

On a side note: Why doesn't audio/video fall back to IBB if ICE fails,
now that IBB is obviously implemented ;)?

That's what TURN tcp is for and it's on our todo list.

Emil

···

On 09 Feb 2014 3:36 PM, "Dominik George" <nik@naturalnet.de> wrote:

Cheers,
Nik

--
Wer den Grünkohl nicht ehrt, ist der Mettwurst nicht wert!

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#3

Hi,

> Why doesn't file transfer use the same methods as audio/video?

Because this hasn't been implemented yet. We did implement pseudo TCP
(Pawel did that in 2012) but we haven't yet got around to integrating
jingle file transfer.

What protocol does it exactly use now? Is it XEP-0096?

In other words, is Jitsi's file transfer compatible to other clients?

Cheers,
Nik

···

--
<burny> Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben
        und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)!

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296


#4

I personally had some problems with gajim to jitsi file transfers, but
i did not yet have the time to find out which one causes problems.

- --
Yannik V�lker

···

Am 09.02.2014 15:58, schrieb Dominik George:

Hi,

Why doesn't file transfer use the same methods as audio/video?

Because this hasn't been implemented yet. We did implement pseudo
TCP (Pawel did that in 2012) but we haven't yet got around to
integrating jingle file transfer.

What protocol does it exactly use now? Is it XEP-0096?

In other words, is Jitsi's file transfer compatible to other
clients?


#5

Yes it is.

--sent from my mobile

···

On 09 Feb 2014 3:59 PM, "Dominik George" <nik@naturalnet.de> wrote:

Hi,

> > Why doesn't file transfer use the same methods as audio/video?
>
> Because this hasn't been implemented yet. We did implement pseudo TCP
> (Pawel did that in 2012) but we haven't yet got around to integrating
> jingle file transfer.

What protocol does it exactly use now? Is it XEP-0096?

In other words, is Jitsi's file transfer compatible to other clients?

Cheers,
Nik

--
<burny> Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben
        und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)!

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#6

I personally had some problems with gajim to jitsi file transfers, but
i did not yet have the time to find out which one causes problems.

Was that something recent or an old memory from 1.x times?

Ingo


#7

Hi,

> What protocol does it exactly use now? Is it XEP-0096?

Yes it is.

In that case, reading the XEP, resuming a broken transfer should be
perfectly possible. I just had a 150 MiB transfer crasah at 95 MiB due
to connection issues on the other end, and now have to restart it from
the beginning.

As the protocol clearly allows for continuing partial transfers, could
we add that to the roadmap somehow :)?

Cheers,
Nik

···

--
<Natureshadow> Auf welchem Server liegt das denn jetzt…?
<mirabilos> Wenn es nicht übers Netz kommt bei Hetzner, wenn es nicht
            gelesen wird bei STRATO, wenn es klappt bei manitu.

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296


#8

As soon as someone volunteers to do the work.

--sent from my mobile

···

On 09 Feb 2014 4:34 PM, "Dominik George" <nik@naturalnet.de> wrote:

Hi,

> > What protocol does it exactly use now? Is it XEP-0096?

> Yes it is.

In that case, reading the XEP, resuming a broken transfer should be
perfectly possible. I just had a 150 MiB transfer crasah at 95 MiB due
to connection issues on the other end, and now have to restart it from
the beginning.

As the protocol clearly allows for continuing partial transfers, could
we add that to the roadmap somehow :)?

Cheers,
Nik

--
<Natureshadow> Auf welchem Server liegt das denn jetzt...?
<mirabilos> Wenn es nicht übers Netz kommt bei Hetzner, wenn es nicht
            gelesen wird bei STRATO, wenn es klappt bei manitu.

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users