[Standards] Jingle (File Transfer) Session termination

Ruslan N. Marchenko me at ruff.mobi
Thu Dec 28 21:41:31 UTC 2017

On 28.12.2017 20:41, Lance Stout wrote:
> 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.
Ok, thanks for a feedback, it matches my understanding as well.
> 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.
That's imprinted in Wocky Jingle implementation and I so far am messing 
with Gabble implementation. So yes, that Ringing message could be 
removed/suppressed/reordered or moved to RTP content handler. Currently 
it's unconditionally fired if content namespace has a consumer - eg. 
once content is parsed and content object is successfully allocated. 
Ack(result) then follows if entire IQ processing hasn't triggered any 
error. I believe TP does this as an early pre-ack expecting that full 
session-initiate processing may take some time to call out all codecs 
and transports (after which only it can send full proper ack/result). 
Perhaps these two should be swapped but hat would require moving entire 
content processing into callback (note to self).
However XEP-0166 6.8 is explicitly calling out that these messages are 
harmless (as you noted above) and should be treated as pings unless 
fully understood.
> 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.
Well it does understand offered file-transfer (in my PoC version), it 
just does not have any client interested in handling this ChannelType 
So yes, ChannelDispatcher just closes the offered channel on sight 
because no client registered a handler for this type (only 
org.freedesktop.Telepathy.Channel.Type.Text) thus no one can accept. And 
that causes a rejection.
I'll need to make some stub auto-accepting client/handler to proceed 
with actual transfer, so far just polishing JingleFT implementation 
> 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.
Yes, that was my initial thought to check disposition=session and 
is-last-content condition and abort entire session. Just tried to 
minimize interaction with jingle library and not to oversee session 
state from content perspective. Will also require Wocky patching.
> 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.
Ok, so the problem may indeed be in the sequence of events. Will check 
gajim implementation if that's the case. I was looking for theoretical 
insight on the jingle state machine as it's new to me. Which you provided :)
> /Lance
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

More information about the Standards mailing list