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
Created attachment 17493 [details]
The gabble log of the initiator
Created attachment 17494 [details]
The gabble log of the recipient
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?)