[Standards] Jingle (File Transfer) Session termination

Ruslan N. Marchenko me at ruff.mobi
Thu Dec 28 15:13:39 UTC 2017


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='me at ruff.mobi/Emush' 
from='ruff at xmpp.zone/gajim.UECVS9Q6'
     * jingle xmlns='urn:xmpp:jingle:1' 
initiator='ruff at 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='ruff at xmpp.zone/gajim.UECVS9Q6' 
id='49488115057'
     * jingle xmlns='urn:xmpp:jingle:1' 
initiator='ruff at 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='me at ruff.mobi/Emush' 
to='ruff at 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='ruff at xmpp.zone/gajim.UECVS9Q6' 
id='55569122241'
     * jingle xmlns='urn:xmpp:jingle:1' 
initiator='ruff at 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='me at ruff.mobi/Emush' 
from='ruff at 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='me at ruff.mobi/Emush' 
from='ruff at 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='ruff at xmpp.zone/gajim.UECVS9Q6' 
id='283410939952'
     * jingle xmlns='urn:xmpp:jingle:1' 
initiator='ruff at 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='me at ruff.mobi/Emush' from='ruff at xmpp.zone/gajim.UECVS9Q6'
     * jingle xmlns='urn:xmpp:jingle:1' 
initiator='ruff at 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='me at ruff.mobi/Emush' 
to='ruff at xmpp.zone/gajim.UECVS9Q6' id='8fbd3391-2f2d-4ccb-af1f-4b363fdc7581'
     * jingle xmlns='urn:xmpp:jingle:1' 
initiator='ruff at xmpp.zone/gajim.UECVS9Q6' 
sid='4ce275a0-f858-4607-8272-418430f14bb1' action='session-terminate'
         * reason
             * success
     * error code='404' type='cancel'
         * item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
         * unknown-session xmlns='urn:xmpp:jingle:errors:1'
         * text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
             "session 4ce275a0-f858-4607-8272-418430f14bb1 is unknown"
which to me looks like in accordance with XEP-0166 Example 29 and its 
preceding abstract.

Finally Gajim ACKs Session-NACK IQ
(telepathy-gabble:3286): wocky-DEBUG: _end_element_ns: Received stanza
* iq xmlns='jabber:client' lang='de' type='result' nsp0='jabber:server' 
id='283410939952' to='me at ruff.mobi/Emush' 
from='ruff at xmpp.zone/gajim.UECVS9Q6'

however transfer session remains in waiting state.

Now the question is - what is proper behaviour here? XEP is explicit for 
this case:
Quote: As soon as an entity sends a session-terminate action, it MUST 
consider the session to be in the ENDED state (even before receiving 
acknowledgement from the other party)

TP follows v032 which already has this statement (736bb5c 
<https://github.com/xsf/xeps/commit/736bb5c9e6db60dc82050245d914cad48ea9fe5c> 
on Oct 8, 2008) so is it a gajim bug or am I missing something here?

Regards,
Ruslan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171228/d401d8b1/attachment.html>


More information about the Standards mailing list