[Standards] Jingle (File Transfer) Session termination
lancestout at gmail.com
Thu Dec 28 19:41:55 UTC 2017
Both sides locally terminated the session, so both sides should be in the ENDED
state. Period. Full stop.
The fact that one side ended up getting an error response to their
session-terminate is irrelevant, because (as you quoted) when locally
terminating the session, the session state moves to ENDED without regard to any
ack from the other side, whether that be a success, error, or no response at
So the session still showing as hanging in the Gajim UI is a client/library bug.
It seems to be waiting for a successful IQ-result before fully cleaning up and
treating the session as ended.
That said, here's a summary of the traffic logs you sent:
|ruff (gajim) me (tp)
1| session-initiate -->
2| <-- session-info
3| <-- iq-result(1)
4| <-- content-reject
5| iq-result(2) -->
6| iq-result(4) -->
7| <-- session-terminate
8| session-terminate -->
9| <-- iq-error(8)
10| iq-result(7) -->
Again, none of this changes the conclusion from above, but looking through this
could be helpful anyway.
The telepathy side is sending a session-info for RTP ringing before even sending
iq-result(1) acknowledging the session-initiate. That's not particularly
harmful here, but it 1) really shouldn't be there at all since there are no RTP
applications involved in the session and 2) should at least have been sent after
iq-result(1). It suggests that Telepathy is probably not queueing local actions,
which could lead to state bugs.
As you stated, the telepathy side doesn't understand the offered file-transfer
application. Telepathy has the correct interpretation here that it should reject
that particular content. To do so, it is sending a content-reject action, which
is perfectly legal. And immediately after doing so, it notices that there are no
remaining contents, and so sends a session-terminate.
That is a perfectly legal sequence of actions to take, but this particular
combination suggests that the Jingle library could be improved here. The spec
mandates that the _receiving_ side of a content-reject or content-remove send
a session-terminate if there are no remaining contents. The, unfortunately
unwritten, implication is that the _sending_ side should just go ahead and send a
session-terminate if it is going to reject or remove the last content. This whole
scenario would have been avoided if Telepathy behaved that way.
The Gajim side of the session after receiving the content-reject dutifully
follows the spec and terminates the session because there are no remaining
We are left in what would otherwise be a tie-breaking situation. Notice
that both sides send a session-terminate before receiving the respective
iq-result/iq-error replies, which means both sides attempted to change the
session in the same ways without being aware of the other also trying to do
so. The tie-breaking rules don't explicitly cover session-terminate (because
once sent, the session is over and tie-breaking wouldn't change anything), but
Gajim (as the tie-winning initiator side) would be valid to reply with an
iq-error(7) with a tie-break error condition.
More information about the Standards