[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 
(org.freedesktop.Telepathy.Channel.Type.FileTransfer).
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 
(parser/state-machine/transports/hookups/etc.).
>
> 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