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 all. 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 contents. 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. /Lance _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
