Bug 16595 - Can't Open StreamTube
Summary: Can't Open StreamTube
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
Depends on:
Reported: 2008-07-03 03:06 UTC by Gagi
Modified: 2019-12-03 19:17 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

The gabble log of the initiator (40.79 KB, application/octet-stream)
2008-07-03 04:49 UTC, Gagi
The gabble log of the recipient (48.95 KB, application/octet-stream)
2008-07-03 04:50 UTC, Gagi

Description Gagi 2008-07-03 03:06:07 UTC
If you try to open a StreamTube to one recipient, the recipient gets the new Tube and accept it. On the recipients side the tube is open and you can get the tube address. But on the initiator side, no tubeStateChanged Signal appears.

On D-Bus Tubes it works correctly, the bug is only on Stream Tubes
Comment 1 Gagi 2008-07-03 04:49:45 UTC
Created attachment 17493 [details]
The gabble log of the initiator
Comment 2 Gagi 2008-07-03 04:50:19 UTC
Created attachment 17494 [details]
The gabble log of the recipient
Comment 3 Alban Crequy 2008-07-15 10:11:39 UTC
In the Gabble current code, the tube is opened automatically in the initiator side as soon as a stream is attempted, that is when the recipient try to really use the tube: see file src/tube-stream.c, function gabble_tube_stream_add_bytestream, line 1409.

When the tube is accepted by the recipient but not used, the tube remains in the "remote pending" status forever on the initiator side.

The current XEP-proto-tube specification does not allow Gabble to behave otherwise:
because the XEP-proto-tube specification does not include any message to say that the recipient has accepted the tube. Instead, the spec send a stream-initiation message to the initiator every time the client connects to the proxied socket.

Note that a single p2p stream tube can contains 0, 1 or several stream at any time when the tube is open. This is required for the web-server-exported-in-a-tube use case.

This can eventually be seen as a bug in the XEP-proto-tube specification because this behavior can prevent the UI to give feedback to the user correctly.

(as a slightly related note, for tubes in a chatroom, the state "remote pending" or "open" on the initiator side is not really defined in the D-Bus spec: should the tube be in the "open" status when a least one recipient accepts it, or when all participants of the chatroom accept it?)
Comment 4 GitLab Migration User 2019-12-03 19:17:50 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/10.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.