Re: [Standards] Jingle (File Transfer) Session termination
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 ru
Re: [Standards] Jingle (File Transfer) Session termination
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: standards-unsubscr...@xmpp.org ___
Re: [Standards] Jingle (File Transfer) Session termination
On 29.11.2017 20:25, Ruslan N. Marchenko wrote: On 29.11.2017 17:42, Jonas Wielicki wrote: Daniel thinks that there are clients which can only do SI, but doesn’t recall any off the top of his head. Telepathy-gabble for one supports only SI. I'm currently looking if i can monkeypatch existing ft-manager to handle jingle but this is in early PoC phase as of yet. I'm lazily progressing in this PoC and stumbled upon certain questionable behaviour. Before claiming it as a (gajim) bug I want some comments. So we have a jingle session which is declined (no handler for this channel type registered hence auto-declined) by Telepathy. However gajim (which I use as a reference implementation for the test) not accepting the decline and lists transfer as hanging till 'unavailable' presence. Session transcript: Incoming session from gajim: (telepathy-gabble:3286): wocky-DEBUG: _end_element_ns: Received stanza * iq xmlns='jabber:client' type='set' lang='de' nsp0='jabber:server' id='d315b7de-c823-4c97-a636-17fd0d5f8692' to='m...@ruff.mobi/Emush' from='r...@xmpp.zone/gajim.UECVS9Q6' * jingle xmlns='urn:xmpp:jingle:1' initiator='r...@xmpp.zone/gajim.UECVS9Q6' sid='4ce275a0-f858-4607-8272-418430f14bb1' action='session-initiate' * content name='fileLREV64SKBODW8GAP' creator='initiator' * description xmlns='urn:xmpp:jingle:apps:file-transfer:3' * offer * file * name "lpcx" * date "2015-01-24T22:37:13" * size "267" * desc * transport xmlns='urn:xmpp:jingle:transports:ibb:1' block-size='4096' sid='9c9e19a0-a383-46c1-8fd1-f1d5407437bc' Intermediate TP ack (TP stack implementation, could be ignored) (telepathy-gabble:3286): wocky-DEBUG: _write_node_tree: Serializing tree: * iq xmlns='jabber:client' type='set' to='r...@xmpp.zone/gajim.UECVS9Q6' id='49488115057' * jingle xmlns='urn:xmpp:jingle:1' initiator='r...@xmpp.zone/gajim.UECVS9Q6' sid='4ce275a0-f858-4607-8272-418430f14bb1' action='session-info' * ringing xmlns='urn:xmpp:jingle:apps:rtp:info:1' TP IQ ACK (telepathy-gabble:3286): wocky-DEBUG: _write_node_tree: Serializing tree: * iq xmlns='jabber:client' type='result' from='m...@ruff.mobi/Emush' to='r...@xmpp.zone/gajim.UECVS9Q6' id='d315b7de-c823-4c97-a636-17fd0d5f8692' TP Jingle Content NACK - this is questionable, again generated by stack but is not violation (unused by FT:3 XEP) (telepathy-gabble:3286): wocky-DEBUG: _write_node_tree: Serializing tree: * iq xmlns='jabber:client' type='set' to='r...@xmpp.zone/gajim.UECVS9Q6' id='55569122241' * jingle xmlns='urn:xmpp:jingle:1' initiator='r...@xmpp.zone/gajim.UECVS9Q6' sid='4ce275a0-f858-4607-8272-418430f14bb1' action='content-reject' * reason * decline * content name='fileLREV64SKBODW8GAP' senders='initiator' creator='initiator' Gajim Jingle ringing IQ ACK (telepathy-gabble:3286): wocky-DEBUG: _end_element_ns: Received stanza * iq xmlns='jabber:client' type='result' lang='de' id='49488115057' nsp0='jabber:server' to='m...@ruff.mobi/Emush' from='r...@xmpp.zone/gajim.UECVS9Q6' Gajim Jingle content-nack IQ ACK (telepathy-gabble:3286): wocky-DEBUG: _end_element_ns: Received stanza * iq xmlns='jabber:client' nsp0='jabber:server' id='55569122241' type='result' lang='de' to='m...@ruff.mobi/Emush' from='r...@xmpp.zone/gajim.UECVS9Q6' TP Jingle Session NACK (telepathy-gabble:3286): wocky-DEBUG: _write_node_tree: Serializing tree: * iq xmlns='jabber:client' type='set' to='r...@xmpp.zone/gajim.UECVS9Q6' id='283410939952' * jingle xmlns='urn:xmpp:jingle:1' initiator='r...@xmpp.zone/gajim.UECVS9Q6' sid='4ce275a0-f858-4607-8272-418430f14bb1' action='session-terminate' * reason * cancel Now this is where I think it's getting stuck. TP deallocates Jingle session by this time, only leaving IQ ACK handler. So when it gets following: (telepathy-gabble:3286): wocky-DEBUG: _end_element_ns: Received stanza * iq xmlns='jabber:client' type='set' lang='de' id='8fbd3391-2f2d-4ccb-af1f-4b363fdc7581' nsp0='jabber:server' to='m...@ruff.mobi/Emush' from='r...@xmpp.zone/gajim.UECVS9Q6' * jingle xmlns='urn:xmpp:jingle:1' initiator='r...@xmpp.zone/gajim.UECVS9Q6' sid='4ce275a0-f858-4607-8272-418430f14bb1' action='session-terminate' * reason * success it replies with (telepathy-gabble:3286): wocky-DEBUG: _write_node_tree: Serializing tree: * iq xmlns='jabber:client' type='error' from='m...@ruff.mobi/Emush' to='r...@xmpp.zone/gajim.UECVS9Q6' id='8fbd3391-2f2d-4ccb-af1f-4b363fdc7581' * jingle xmlns='urn:xmpp:jingle:1' initiator='r...@xmpp.zone/gajim.UECVS9Q6' sid='4ce275a0-f858-4607-8272-418430f14bb1' action='session-terminate' * reason * success * error code='404' type='cancel'
